leahneukirchen/mblaze

Unix utilities to deal with Maildir

mblaze's Issues

Important: mcom empties drafts!

When I have a draft but it somehow got messed up (no idea what I did though) and try to send it I can't see the errors (can't parse range) because I instantly get into the feedback loop (menu).

I chose send (because I wasn't aware of the errors) and it tried to send but destroyed the draft file! It said it will keep the draft, but the file was empty. The example.txt.mine was alright, but the mail itself (example.txt) was empty.

The following is my shell output.

used draft example.txt
can't parse range: example.txt
can't parse range: example.txt
What now? (mime and [s]end, [c]ancel, [d]elete, [e]dit, [m]ime, sign, encrypt) s
can't parse range: example.txt
can't parse range: example.txt
can't parse range: example.txt.mime
msmtp: keine Empfänger gefunden
mcom: /usr/bin/msmtp -t failed, kept draft example.txt

Using "Outbox" with multiple accounts

It would be really nice if I could specify different Outbox values for different mail accounts in my ~/.mblaze/profile.

Is my understanding correct, that currently all mail I write will be saved in the same Outbox-maildir, no matter what the from address was? How do you deal with this?

Build fails on OpenBSD 6.1 (MacPPC) - undefined reference to `sigwait' in filter.c

At least, I think that's the point where it's failing; see full build log below.

(I wanted to test mshow -x on a different OS......)

cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o rfc2047.o rfc2047.c
cc   maddr.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o rfc2047.o  -L/usr/local/lib -liconv -o maddr
blaze822.o: In function `blaze822_addr':
/home/larry/mblaze/blaze822.c:219: warning: warning: strcpy() is almost always misused, please use strlcpy()
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o magrep.o magrep.c
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o rfc2045.o rfc2045.c
cc   magrep.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o rfc2047.o rfc2045.o  -L/usr/local/lib -liconv -o magrep
blaze822.o: In function `blaze822_addr':
/home/larry/mblaze/blaze822.c:219: warning: warning: strcpy() is almost always misused, please use strlcpy()
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mdate.o mdate.c
cc   mdate.o  -L/usr/local/lib -liconv -o mdate
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mdeliver.o mdeliver.c
mdeliver.c: In function 'deliver':
mdeliver.c:82: warning: format '%ld' expects type 'long int', but argument 4 has type 'time_t'
cc   mdeliver.o blaze822.o mymemmem.o mytimegm.o  -L/usr/local/lib -liconv -o mdeliver
blaze822.o: In function `blaze822_addr':
/home/larry/mblaze/blaze822.c:219: warning: warning: strcpy() is almost always misused, please use strlcpy()
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mdirs.o mdirs.c
cc   mdirs.o  -L/usr/local/lib -liconv -o mdirs
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mexport.o mexport.c
cc   mexport.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o  -L/usr/local/lib -liconv -o mexport
blaze822.o: In function `blaze822_addr':
/home/larry/mblaze/blaze822.c:219: warning: warning: strcpy() is almost always misused, please use strlcpy()
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mflag.o mflag.c
cc   mflag.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o  -L/usr/local/lib -liconv -o mflag
blaze822.o: In function `blaze822_addr':
/home/larry/mblaze/blaze822.c:219: warning: warning: strcpy() is almost always misused, please use strlcpy()
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mgenmid.o mgenmid.c
cc   mgenmid.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o  -L/usr/local/lib -liconv -o mgenmid
blaze822.o: In function `blaze822_addr':
/home/larry/mblaze/blaze822.c:219: warning: warning: strcpy() is almost always misused, please use strlcpy()
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mhdr.o mhdr.c
mhdr.c: In function 'print_date':
mhdr.c:89: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t'
cc   mhdr.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o rfc2047.o  -L/usr/local/lib -liconv -o mhdr
blaze822.o: In function `blaze822_addr':
/home/larry/mblaze/blaze822.c:219: warning: warning: strcpy() is almost always misused, please use strlcpy()
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o minc.o minc.c
cc   minc.o  -L/usr/local/lib -liconv -o minc
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mlist.o mlist.c
cc   mlist.o seq.o slurp.o  -L/usr/local/lib -liconv -o mlist
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mmime.o mmime.c
cc   mmime.o slurp.o  -L/usr/local/lib -liconv -o mmime
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mpick.o mpick.c
mpick.c: In function 'parse_dur':
mpick.c:529: warning: missing initializer
mpick.c:529: warning: (near initialization for 'tm.tm_min')
mpick.c: In function 'parse_cmp':
mpick.c:331: warning: 'op' may be used uninitialized in this function
mpick.c:331: note: 'op' was declared here
mpick.c: In function 'main':
mpick.c:688: warning: 'flag' may be used uninitialized in this function
mpick.c:688: note: 'flag' was declared here
cc   mpick.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o rfc2047.o  -L/usr/local/lib -liconv -o mpick
blaze822.o: In function `blaze822_addr':
/home/larry/mblaze/blaze822.c:219: warning: warning: strcpy() is almost always misused, please use strlcpy()
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mscan.o mscan.c
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o pipeto.o pipeto.c
cc   mscan.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o rfc2047.o pipeto.o  -L/usr/local/lib -liconv -o mscan
blaze822.o: In function `blaze822_addr':
/home/larry/mblaze/blaze822.c:219: warning: warning: strcpy() is almost always misused, please use strlcpy()
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o msed.o msed.c
cc   msed.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o  -L/usr/local/lib -liconv -o msed
blaze822.o: In function `blaze822_addr':
/home/larry/mblaze/blaze822.c:219: warning: warning: strcpy() is almost always misused, please use strlcpy()
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mseq.o mseq.c
mseq.c: In function 'main':
mseq.c:311: warning: missing initializer
mseq.c:311: warning: (near initialization for 'iter.cur')
cc   mseq.o seq.o slurp.o  -L/usr/local/lib -liconv -o mseq
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mshow.o mshow.c
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o filter.o filter.c
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o safe_u8putstr.o safe_u8putstr.c
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o rfc2231.o rfc2231.c
cc   mshow.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o rfc2047.o rfc2045.o filter.o safe_u8putstr.o rfc2231.o pipeto.o  -L/usr/local/lib -liconv -o mshow
blaze822.o: In function `blaze822_addr':
/home/larry/mblaze/blaze822.c:219: warning: warning: strcpy() is almost always misused, please use strlcpy()
filter.o: In function `filter':
/home/larry/mblaze/filter.c:120: undefined reference to `sigwait'
collect2: ld returned 1 exit status
gmake: *** [<builtin>: mshow] Error 1

Missing manpages

• mnext and mprev (likely as part of the mless manpage)
• mdate
• mquote

mless: Making use of the switch in the "main loop"

Browsing mless's source, I notice a "main loop" with an inner case statement. It looks to be switching on the exit code of less, supposedly letting one do convenient things like mark messages read, toggle raw/html modes, etc. from within mless. The exit codes acting as ascii codes is nifty.

This behaviour is completely undocumented in mless(1) and, reading through less(1) I can find no way to produce the necessary exit codes. Am I simply missing something obvious?

make fails, on OS X, with use of sigtimedwait in filter.c

With the addition of sigtimedwait to filter.c, make fails on OS X:

cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o maddr.o maddr.c
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o blaze822.o blaze822.c
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mymemmem.o mymemmem.c
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mytimegm.o mytimegm.c
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o seq.o seq.c
seq.c:518:38: warning: missing field 'cur' initializer [-Wmissing-field-initializers]
        struct blaze822_seq_iter iter = { 0 };
                                            ^
1 warning generated.
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o slurp.o slurp.c
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o rfc2047.o rfc2047.c
cc   maddr.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o rfc2047.o  -L/usr/local/lib -liconv -o maddr
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o magrep.o magrep.c
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o rfc2045.o rfc2045.c
cc   magrep.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o rfc2047.o rfc2045.o  -L/usr/local/lib -liconv -o magrep
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mdate.o mdate.c
cc   mdate.o  -L/usr/local/lib -liconv -o mdate
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mdeliver.o mdeliver.c
mdeliver.c:82:16: warning: format specifies type 'long' but the argument has type '__darwin_suseconds_t' (aka 'int') [-Wformat]
                         tv.tv_sec, tv.tv_usec, (long)getpid(), delivery, host);
                                    ^~~~~~~~~~
/usr/include/secure/_stdio.h:57:62: note: expanded from macro 'snprintf'
  __builtin___snprintf_chk (str, len, 0, __darwin_obsz(str), __VA_ARGS__)
                                                             ^
1 warning generated.
cc   mdeliver.o blaze822.o mymemmem.o mytimegm.o  -L/usr/local/lib -liconv -o mdeliver
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mdirs.o mdirs.c
cc   mdirs.o  -L/usr/local/lib -liconv -o mdirs
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mexport.o mexport.c
cc   mexport.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o  -L/usr/local/lib -liconv -o mexport
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mflag.o mflag.c
cc   mflag.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o  -L/usr/local/lib -liconv -o mflag
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mgenmid.o mgenmid.c
cc   mgenmid.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o  -L/usr/local/lib -liconv -o mgenmid
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mhdr.o mhdr.c
cc   mhdr.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o rfc2047.o  -L/usr/local/lib -liconv -o mhdr
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o minc.o minc.c
cc   minc.o  -L/usr/local/lib -liconv -o minc
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mlist.o mlist.c
cc   mlist.o seq.o slurp.o  -L/usr/local/lib -liconv -o mlist
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mmime.o mmime.c
cc   mmime.o slurp.o  -L/usr/local/lib -liconv -o mmime
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mpick.o mpick.c
mpick.c:523:21: warning: missing field 'tm_min' initializer [-Wmissing-field-initializers]
        struct tm tm = { 0 };
                           ^
1 warning generated.
cc   mpick.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o rfc2047.o  -L/usr/local/lib -liconv -o mpick
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mscan.o mscan.c
cc   mscan.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o rfc2047.o  -L/usr/local/lib -liconv -o mscan
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o msed.o msed.c
cc   msed.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o  -L/usr/local/lib -liconv -o msed
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mseq.o mseq.c
mseq.c:311:38: warning: missing field 'cur' initializer [-Wmissing-field-initializers]
        struct blaze822_seq_iter iter = { 0 };
                                            ^
1 warning generated.
cc   mseq.o seq.o slurp.o  -L/usr/local/lib -liconv -o mseq
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o mshow.o mshow.c
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o filter.o filter.c
filter.c:108:2: warning: implicit declaration of function 'sigtimedwait' is invalid in C99 [-Wimplicit-function-declaration]
        sigtimedwait(&mask, 0, &immediately);
        ^
1 warning generated.
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o safe_u8putstr.o safe_u8putstr.c
cc -g -O2 -Wall -Wno-switch -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/usr/local/include   -c -o rfc2231.o rfc2231.c
cc   mshow.o blaze822.o mymemmem.o mytimegm.o seq.o slurp.o rfc2047.o rfc2045.o filter.o safe_u8putstr.o rfc2231.o  -L/usr/local/lib -liconv -o mshow
Undefined symbols for architecture x86_64:
  "_sigtimedwait", referenced from:
      _filter in filter.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [mshow] Error 1

Compiling on OSX

Hi

I don't know if you're interested in supporting OSX. (I'm stuck with it - for now - as my main machine.)

Anyway, OSX doesn't 'have' clock_gettime. Using this patch, for the st terminal emulator I am able to get mblaze to compile and run on OSX (I apologise for what I assume is butchery of some scale, but I'm out of my depth), by patching mgenmid.c as follows:

diff --git a/mgenmid.c b/mgenmid.c
index 7464daa..d3a08fe 100644
--- a/mgenmid.c
+++ b/mgenmid.c
@@ -13,6 +13,20 @@
 
 #include "blaze822.h"
 
+#ifdef __MACH__
+#include <sys/time.h>
+//clock_gettime is not implemented on OSX
+#define CLOCK_MONOTONIC -1
+int clock_gettime(int clk_id /*clk_id*/, struct timespec* t) {
+    struct timeval now;
+    int rv = gettimeofday(&now, NULL);
+    if (rv) return rv;
+    t->tv_sec  = now.tv_sec;
+    t->tv_nsec = now.tv_usec * 1000;
+    return 0;
+}
+#endif
+
 void
 printb36(uint64_t x)
 {
@@ -81,7 +95,7 @@ int main()
 	}
 		
 	struct timespec tp;
-	clock_gettime(CLOCK_REALTIME, &tp);
+	clock_gettime(CLOCK_MONOTONIC, &tp);
 
 	uint64_t rnd;

Option for mrep/mbnc/mfwd to delete body?

So I've written some rules for automatic filtering of emails and found it would be quite useful to add an option to delete the content of an email except headers so that I only send whatever I expected with the -body argument.

Should be fairly easy to add too!

mhtml: Simple script to view HTML emails in browser

#!/bin/sh

msg="${1:-$(mseq)}"
tf=$(mktemp '/tmp/mhtml.XXXXXX.html')
hp=$(mshow -t "${msg}" | grep 'text/html' | cut -d ':' -f 1 | xargs)
mshow -O "${msg}" "${hp}" | sed 's/^[[:blank:]]*//;s/[[:blank:]]*$//' | sed '/^$/d' > "${tf}"
"${BROWSER:-xdg-open}" "${tf}"
sleep 1
rm "${tf}"

Man: colon or semicolon in single quotes is not rendered properly

Example:

.Sq Cm ":"

is rendered as

'':

This happens in mmsg.7, msed.1 and mscan.1. Can you reproduce this?

GNU nroff (groff) version 1.22.3
man 2.7.6.1

mcom does not delete file when quitting $EDITOR with RC !=0

When I open a new message up via mcom and quit my editor (vim) using :cq, causing it to return 1 as RC it will not delete the snd.0 file even though it tells me it did cancel: mcom: cancelled draft ./snd.0.

I think since we don't want to delete files that were previously there it would be good to check if the file has been there before or is created (store a flag somewhere in the code) and if its created but cancelled remove it.

Build fails on GNU/Hurd

@ucko filed a Debian bug report about mblaze failing to build on Hurd, do to PATH_MAX not being defined.

I suggest we either lookup the size via pathconf, or default to 4096.
If that's alright by you, I can submit a patch for this.

mseq -f ignores messages flagged as trashed

While attempting to implement a 'mark as trashed' key in mless(1), I noticed that mseq -f : ignores messages marked as trashed. Simple case:

$ mscan
    1   obsd/ Sun May 14 Stefan Sperling     Re: iwm0: could not initiate scan
    2   obsd/ Mon May 22 Stefan Sperling     Re: OpenBSD 6.1 on Lenovo P50
    3   obsd/ Tue Jun 20 Anthony J. Bentle   Re: vi(1): documenting :s
    4   obsd/ Fri Jun 23 Eike Lantzsch       Re: Fwd: gpu for desktop
    5   obsd/ Fri Jun 23 Mike Coddington     Re: gpu for desktop
5 mails scanned

$ mflag -T 1
/Users/larry/mail/mail/obsd/cur/1494773196.80126_0.sutro.larryhynes.com:2,ST

$ mseq -f :
/Users/larry/mail/mail/obsd/cur/1495476765.4687_0.sutro.larryhynes.com:2,S
/Users/larry/mail/mail/obsd/cur/1497945452.30814_0.sutro.larryhynes.com:2,S
/Users/larry/mail/mail/obsd/cur/1498225852.43671_0.sutro.larryhynes.com:2,S
/Users/larry/mail/mail/obsd/cur/1498235152.59088_0.sutro.larryhynes.com:2,S

I haven't tested every flag, but -s and -F both get 'fixed' by mseq -f:

mflag -s 2
/Users/larry/mail/mail/obsd/cur/1495476765.4687_0.sutro.larryhynes.com:2,

$ mseq -f :
/Users/larry/mail/mail/obsd/cur/1495476765.4687_0.sutro.larryhynes.com:2,
/Users/larry/mail/mail/obsd/cur/1497945452.30814_0.sutro.larryhynes.com:2,S
/Users/larry/mail/mail/obsd/cur/1498225852.43671_0.sutro.larryhynes.com:2,S
/Users/larry/mail/mail/obsd/cur/1498235152.59088_0.sutro.larryhynes.com:2,S

mflag -F 3
/Users/larry/mail/mail/obsd/cur/1497945452.30814_0.sutro.larryhynes.com:2,FS

$ mseq -f :
/Users/larry/mail/mail/obsd/cur/1495476765.4687_0.sutro.larryhynes.com:2,
/Users/larry/mail/mail/obsd/cur/1497945452.30814_0.sutro.larryhynes.com:2,FS
/Users/larry/mail/mail/obsd/cur/1498225852.43671_0.sutro.larryhynes.com:2,S
/Users/larry/mail/mail/obsd/cur/1498235152.59088_0.sutro.larryhynes.com:2,S

$ mflag -T 4
/Users/larry/mail/mail/obsd/cur/1498225852.43671_0.sutro.larryhynes.com:2,ST

$ mseq -f :
/Users/larry/mail/mail/obsd/cur/1495476765.4687_0.sutro.larryhynes.com:2,
/Users/larry/mail/mail/obsd/cur/1497945452.30814_0.sutro.larryhynes.com:2,FS
/Users/larry/mail/mail/obsd/cur/1498235152.59088_0.sutro.larryhynes.com:2,S

pledge()

Mail is one of the major sources of untrusted input on my system. It would be nice to start dropping privileges in the various programs with pledge(2).

mshow/mflow doesn’t display EBCDIC-encoded bodies correctly

If you read this subject and ask yourself “What in the name of—?!”, yes, exactly. This is cursed and should really not be a real-world issue, but I still consider it a bug.

When invoked on a mail that contains EBCDIC-coded headers and body, mshow will decode and display the headers correctly; the body, however, not. I’m not really sure whether this is an issue with mshow or mflow.

Steps to reproduce: invoke mshow (with text/plain: mflow in .mblaze/filter) on this mail.

From: =?EBCDIC-INT?B?44iWlIGiQOKDiJWFiYSFmQ==?= <[email protected]>
To: =?EBCDIC-INT?B?44iWlIGiQOKDiJWFiYSFmQ==?= <[email protected]>
Date: Tue, 04 Dec 2018 16:55:15 +0100
Subject: =?EBCDIC-INT?B?44iJokCipIKRhYOjQImiQImVQMXCw8TJww==?=
Content-Type: text/plain; charset="EBCDIC-INT"
Content-Transfer-Encoding: base64
Message-ID: <[email protected]>

44iFQJikiYOSQIKZlqaVQIaWp0CRpJSXokCWpYWZQKOIhUCTgamoQISWh0sl

Results:

% mshow ./ebcdic-mail
From: Thomas Schneider <[email protected]>
Subject: This subject is in EBCDIC
To: Thomas Schneider <[email protected]>
Date: Tue, 04 Dec 2018 16:55:15 +0100 (14 minutes, 54 seconds ago)

--- 1: text/plain size=45 charset="EBCDIC-INT" render="mflow" ---
㈅@␛␘¤␛␉␛␃␛␒@␛␂␛␙␛␖¦␛␕@␛␆␛␖§@␛␑¤␛␔␛␗¢@␛␖¥␛␅␛␙@£␛␈␛␅@␛␓␛␁©¨@␛␄␛␖␛␇K%

Your results may differ based on your locale and whatnot.

Expected results: the body should display “The quick brown fox jumps over the lazy dog.”

mcom(1): do_mime portability on macOS

mcom(1)'s do_mime calls file -Lbi to get a mime-type for a file to be attached. On macOS, the -i option to the vendor's /usr/bin/file means something else, the flag to print a mime-type instead of the human-readable string from the magic file is -I (uppercase i). I'd propose a patch but I have no ideas offhand about how to handle this.

mdir | mlist

First: thank you a lot for this very great mail project.

I use it along with s-nail, with isync, and I have not done any script for it yet, so I do mlist . $(mdir) every time.

I feel it is slightly less pleasant than to type only pipes mdir | mlist | mscan.

1. Make mdir act on current directory if no directory is given from the command line, as find does ?
2. Make mlist take stdin if no directory is given from command line as mscan does?

These are tiny improvement without much importance.

Thank you again for this mblaze project.

PGP/MIME support

I hope this is not considered spam here.

Is any PGP/MIME 1 2 3 or PGP/Inline support planned in mcom/mrep?
Or would a patch implementing these be accepted either in mcom itself or
as a patch in contrib?

Greetings,

pranomostro

"unseen" has higher priority than "trashed" in mscan

It's just a matter of the order in the if/else, but this leads to odd behavior when a message is marked as trash without being read (e.g. if the subject indicates it's spam)

How to use with multiple accounts

I've installed msmtp and mailx and configured ~/.mailrc to have all my 5 email accounts.

How do I for example tell mcom which account to use when sending the mail?

Edit: Just found out about https://github.com/chneukirchen/mblaze/blob/master/man/mblaze-profile.5, I will take a look.

magrep crash when decoding large messages

From /var/log/messages:

magrep: stack overflow in function magrep

Backtrace:

(gdb) run -d To:blah /tmp/,43446
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /tmp/mblaze/magrep -d To:[email protected] /tmp/,43446
could not read sequence '/home/anthony/.mblaze/seq': No such file or directory
/tmp/,43446

Program received signal SIGABRT, Aborted.
thrkill () at -:3
3       -: No such file or directory.
(gdb) bt
#0  thrkill () at -:3
#1  0x000009545e78f89b in _libc___stack_smash_handler (func=<optimized out>, 
    damaged=<optimized out>) at /usr/src/lib/libc/sys/stack_protector.c:79
#2  0x0000095199800f6c in magrep (file=0x7f7ffffebb05 "/tmp/,43446")
    at magrep.c:159
#3  0x00000951998041d3 in iterdir (dir=0x7f7ffffebb05 "/tmp/,43446", 
    cb=<optimized out>) at seq.c:481
#4  blaze822_loop (argc=<optimized out>, argv=<optimized out>, 
    cb=0x95199800d40 <magrep>) at seq.c:536
#5  0x00000951998010db in main (argc=<optimized out>, argv=0x7f7ffffeb918)
    at magrep.c:203

I can reproduce with the following file (I just added addresses until it started crashing):

To: "John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>,
	"John Doe" <[email protected]>

allow customization of mscan symbols

I'd really like to be able to customize the glyphs mscan uses for its output. See also: http://nerdfonts.com/

Should 'mpick n' be zero-based, or one-based?

Hi

In a situation like this:

$ mlist mail/archive/ | tail -5
mail/archive//cur/1493046941.1011_0.sutro.larryhynes.com:2,RS
mail/archive//cur/1493071673.40575_0.sutro.larryhynes.com:2,RS
mail/archive//cur/1493107695.94987_0.sutro.larryhynes.com:2,RS
mail/archive//cur/1493107696.94989_0.sutro.larryhynes.com:2,S
mail/archive//cur/1493141199.48570_0.sutro.larryhynes.com:2,S

$ mlist mail/archive/ | tail -5 | mseq -S

$ mpick 0:4
mail/archive//cur/1493046941.1011_0.sutro.larryhynes.com:2,RS
mail/archive//cur/1493071673.40575_0.sutro.larryhynes.com:2,RS
mail/archive//cur/1493107695.94987_0.sutro.larryhynes.com:2,RS
mail/archive//cur/1493107696.94989_0.sutro.larryhynes.com:2,S
mail/archive//cur/1493141199.48570_0.sutro.larryhynes.com:2,S
5 mails tested, 5 picked.

I would expect mpick 1:5 to return what mpick 0:4 is returning here i.e. to match the msg numbers that would be listed by mscan. Instead mpick 1:5 returns:

mail/archive//cur/1493071673.40575_0.sutro.larryhynes.com:2,RS
mail/archive//cur/1493107695.94987_0.sutro.larryhynes.com:2,RS
mail/archive//cur/1493107696.94989_0.sutro.larryhynes.com:2,S
mail/archive//cur/1493141199.48570_0.sutro.larryhynes.com:2,S
5 mails tested, 4 picked.

So I'm wondering if mpick should be one-based, like mscan, or is it intended to be zero-based? Like, mscan returns:

$ mscan
  - 1   / Mon Apr 24 someone@somewhere  > foo
  - 2   / Mon Apr 24 someone@else > Re: bar
  - 3   / Tue Apr 25 someone@else > Re: bar
    4   / Tue Apr 25 someone@else > Re: bar
    5   / Tue Apr 25 someone@somewhere  > Re: foo
5 mails scanned

but if I want to operate on that sequence with mpick n, I have to subtract one from each msg number.

mpick messages which have been flagged with mflag

Having applied the flags S and T with mflag, I would expect mpick to pick those messages, using the test for trashed (or seen, or either/both)...

$ mlist .mail/inbox
.mail/inbox/cur/1490462878.95690_0.sutro.larryhynes.com:2,ST
.mail/inbox/cur/1490613356.59772_0.sutro.larryhynes.com:2,ST
.mail/inbox/cur/1490656715.32897_0.sutro.larryhynes.com:2,ST
.mail/inbox/cur/1490691433.86410_0.sutro.larryhynes.com:2,ST

$ mlist .mail/inbox | mpick -t 'trashed'
4 mails tested, 0 picked.

$ mlist .mail/inbox | mpick -t '!trashed'
.mail/inbox/cur/1490462878.95690_0.sutro.larryhynes.com:2,ST
.mail/inbox/cur/1490613356.59772_0.sutro.larryhynes.com:2,ST
.mail/inbox/cur/1490656715.32897_0.sutro.larryhynes.com:2,ST
.mail/inbox/cur/1490691433.86410_0.sutro.larryhynes.com:2,ST
4 mails tested, 4 picked.

 $ mlist .mail/inbox/ | mpick :T
4 mails tested, 0 picked.

And then things get a little weird, when :S matches, then doesn't:

$ mlist .mail/inbox/ | mpick :S
.mail/inbox//cur/1490462878.95690_0.sutro.larryhynes.com:2,ST
.mail/inbox//cur/1490613356.59772_0.sutro.larryhynes.com:2,ST
.mail/inbox//cur/1490656715.32897_0.sutro.larryhynes.com:2,ST
.mail/inbox//cur/1490691433.86410_0.sutro.larryhynes.com:2,ST
4 mails tested, 4 picked.

 $ mlist .mail/inbox/ | mpick :T
4 mails tested, 0 picked.

$ mlist .mail/inbox/ | mpick :S
4 mails tested, 0 picked.

What am I missing here?

Question: How to auto sign emails?

So I was wondering how do you automatically sign emails (gpg)? I‘m new to email signing so that idea may be stupid... just let me know how you handle email signing. I am not sending emails with a lot of people so I guess there would be no problem sending my key to those I communicate to so all my emails can be signed by default.

Thanks and have a great day!

minc double slashes

Similar problem as was in mlist:

term% minc mail/inbox/
mail/inbox//cur/1499794207.13948_0.localhost:2,

Problems with special characters using mencrypt and mmime

I've noticed that when I encrypt a message that contains special characters like à, é, send it to myself, and decrypt it, the characters don't display well anymore. Digging a bit, I see that when calling mmime on a message that contains such characters, they become unreadable (example below). How can I read them properly? Am I misunderstanding how mmime works?

The ultimate question is how can I read special characters properly when decoding an email that was encoded with mencrypt?

For example, with the following content in the file "msgtest":

To: [email protected]
Cc: 
Bcc: 
Subject: 
From: [email protected]
Message-Id: <[email protected]>
User-Agent: mblaze/0.5.1-13-g1ed8a0a-dirty (2019-09-05)

accents: à é

The mmime command gives:

guillaume@guillaume-portable ~/tmp> mmime < msgtest
To: [email protected]
Cc:
Bcc:
Subject:
From: [email protected]
Message-Id: <[email protected]>
User-Agent: mblaze/0.5.1-13-g1ed8a0a-dirty (2019-09-05)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_462810cc62ddba987fdf34f3_=_"

This is a multipart message in MIME format.

------_=_462810cc62ddba987fdf34f3_=_
Content-Type: text/plain; charset=UTF-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

accents: =C3=A0 =C3=A9

------_=_462810cc62ddba987fdf34f3_=_--

Thanks

message refused: Message is not RFC 2822 compliant

OpenSMTPD on OpenBSD 6.0 is rejecting replies to a particular message, with the error:

smtp event=failed-command command="DATA" result="550 5.7.1 Delivery not authorized, message refused: Message is not RFC 2822 compliant"

I don't think there's anything particularly out of the ordinary in the message that I'm trying to send, and replies to this person have been going through today already, so I'm a bit stumped. I'm also aware that debugging this could take a lot of time!

Are there any known 'gotcha' areas regarding RFC compliance and mblaze?

New test issue

This just tests webhook integration.

Bug: mcom does not handle quoted filenames

When I pass -attach "<filename>" or -attach '<filename>' to mcom and return to the selection menu it will prompt me for every attachment that it cannot be found (it will try to quote it once resulting in the path to be "'<filename>'" or ""<filename>"".

mlist -i ignores mails in maildir/new

Filenames in maidir/new doesn't have maildir info part. The format is uniq and not uniq:info according to https://cr.yp.to/proto/maildir.html .

But mlist -i skips file entries if it doesn't contains ":2," substring, resulting ignoring any message in maildir/new.

The following commands permits to reproduce the problem:

# create maildir with few messages
$ mkdir -p maildir/{new,tmp,cur}
$ touch maildir/cur/1325341040.3.localhost:2, maildir/new/1325341040.1.localhost maildir/new/1325341040.2.localhost

$ mlist maildir
maildir/cur/1325341040.3.localhost:2,
maildir/new/1325341040.1.localhost
maildir/new/1325341040.2.localhost

$ mlist -i maildir
     1 unseen    0 flagged       1 msg  maildir

mlist -i reports only 1 message (instead of 3) and 1 unseen (instead of 3).

Filters hang in a loop without returning

(Again, this may be OSX-specific, and may well be related to the renowned brokenness of poll on OSX.)

No filter, that I've tried, on any type/subtype, will return its output to the screen and allow mshow to continue processing; it just hangs indefinitely and has to be aborted.

A trace reveals that the filter does actually return its output (the line:

read(0x5, "This is a test, with some html formatting, and an attachment.\n\n\n\0", 0x200)		 = 64 0

below), but for some reason it doesn't make it as far as the tty. Example, using the 'default' text/html filter:

SYSCALL(args) 		 = return
thread_selfid(0x0, 0x0, 0x0)		 = 3264522 0
csops(0x0, 0x0, 0x7FFF56447228)		 = 0 0
issetugid(0x0, 0x0, 0x7FFF56447228)		 = 0 0
shared_region_check_np(0x7FFF56445168, 0x0, 0x7FFF56447228)		 = 0 0
stat64("/usr/lib/dtrace/libdtrace_dyld.dylib\0", 0x7FFF564462F8, 0x7FFF56447228)		 = 0 0
open("/usr/lib/dtrace/libdtrace_dyld.dylib\0", 0x0, 0x0)		 = 3 0
pread(0x3, "\312\376\272\276\0", 0x1000, 0x0)		 = 4096 0
pread(0x3, "\317\372\355\376\a\0", 0x1000, 0x1000)		 = 4096 0
fcntl(0x3, 0x3D, 0x7FFF56444660)		 = 0 0
mmap(0x1097CB000, 0x2000, 0x5, 0x12, 0x3, 0x1000)		 = 0x1097CB000 0
mmap(0x1097CD000, 0x1000, 0x3, 0x12, 0x3, 0x3000)		 = 0x1097CD000 0
mmap(0x1097CE000, 0x1FC0, 0x1, 0x12, 0x3, 0x4000)		 = 0x1097CE000 0
close(0x3)		 = 0 0
stat64("/usr/lib/dtrace/libdtrace_dyld.dylib\0", 0x7FFF56446C78, 0x1)		 = 0 0
stat64("/usr/lib/libiconv.2.dylib\0", 0x7FFF56446118, 0x1)		 = 0 0
stat64("/usr/lib/libSystem.B.dylib\0", 0x7FFF56446118, 0x1)		 = 0 0
stat64("/usr/lib/system/libcache.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libcommonCrypto.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libcompiler_rt.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libcopyfile.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libcorecrypto.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libdispatch.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libdyld.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libkeymgr.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/liblaunch.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libmacho.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libquarantine.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libremovefile.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_asl.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_blocks.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_c.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_configuration.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_coreservices.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_coretls.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_dnssd.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_info.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_kernel.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_m.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_malloc.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_network.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_networkextension.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_notify.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_platform.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_pthread.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_sandbox.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_secinit.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_stats.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libsystem_trace.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libunc.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libunwind.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/system/libxpc.dylib\0", 0x7FFF56445C28, 0x1)		 = 0 0
stat64("/usr/lib/libobjc.A.dylib\0", 0x7FFF56444F08, 0x1)		 = 0 0
stat64("/usr/lib/libauto.dylib\0", 0x7FFF56444F08, 0x1)		 = 0 0
stat64("/usr/lib/libc++abi.dylib\0", 0x7FFF56444DE8, 0x1)		 = 0 0
stat64("/usr/lib/libc++.1.dylib\0", 0x7FFF56444DE8, 0x1)		 = 0 0
stat64("/usr/lib/libDiagnosticMessagesClient.dylib\0", 0x7FFF56444CD8, 0x1)		 = 0 0
getpid(0x7FFF8ED9B740, 0x7FFF56444CD8, 0x1)		 = 36802 0
open("/dev/dtracehelper\0", 0x2, 0x7FFF56447120)		 = 3 0
ioctl(0x3, 0x80086804, 0x7FFF564470A8)		 = 0 0
close(0x3)		 = 0 0
sysctl(0x7FFF56446748, 0x2, 0x7FFF56446758)		 = 0 0
thread_selfid(0x7FFF56446748, 0x2, 0x7FFF56446758)		 = 3264522 0
bsdthread_register(0x7FFF8E7FE3E0, 0x7FFF8E7FE3D0, 0x2000)		 = 1073741855 0
mprotect(0x1097C8000, 0x88, 0x1)		 = 0 0
mprotect(0x1097D0000, 0x1000, 0x0)		 = 0 0
mprotect(0x1097E6000, 0x1000, 0x0)		 = 0 0
mprotect(0x1097E7000, 0x1000, 0x0)		 = 0 0
mprotect(0x1097FD000, 0x1000, 0x0)		 = 0 0
mprotect(0x1097CA000, 0x1000, 0x1)		 = 0 0
mprotect(0x1097C8000, 0x88, 0x3)		 = 0 0
mprotect(0x1097C8000, 0x88, 0x1)		 = 0 0
issetugid(0x1097C8000, 0x88, 0x1)		 = 0 0
getpid(0x1097C8000, 0x88, 0x1)		 = 36802 0
stat64("/AppleInternal/XBS/.isChrooted\0", 0x7FFF564466A8, 0x1)		 = -1 Err#2
stat64("/BuildSupport/makeProject\0", 0x7FFF564466A8, 0x1)		 = -1 Err#2
stat64("/AppleInternal\0", 0x7FFF56446618, 0x1)		 = -1 Err#2
csops(0x8FC2, 0x7, 0x7FFF56446140)		 = -1 Err#22
csops(0x8FC2, 0x7, 0x7FFF56445A20)		 = -1 Err#22
open("/Users/larry/.mblaze/filter\0", 0x0, 0x8)		 = 3 0
read(0x3, "#:text/plain: t-prot --body --bigq -mces --diff --fixind -l -L ~/t-prot\ntext/html: lynx -dump -stdin -nomargins ${PIPE_CHARSET:+-assume_charset $PIPE_CHARSET}\n#:image: file -b -\n\0", 0x1000)		 = 178 0
read(0x3, "\0", 0x1F4E)		 = 0 0
close(0x3)		 = 0 0
ioctl(0x0, 0x4004667A, 0x7FFF56447ACC)		 = 0 0
open("/Users/larry/.mblaze/seq\0", 0x0, 0x7FFF56447690)		 = 3 0
fstat64(0x3, 0x7FFF56447570, 0x7FFF56447690)		 = 0 0
read(0x3, "/Users/larry/.mail/logs/cur/1490538571.34923_0.sutro.larryhynes.com:2,\n/Users/larry/.mail/logs/cur/1490538572.34927_0.sutro.larryhynes.com:2,\n/Users/larry/.mail/obsd/cur/1490538571.34921_0.sutro.larryhynes.com:2,\n/Users/larry/.mail/obsd/cur/1490538572.3492", 0x11C)		 = 284 0
close(0x3)		 = 0 0
readlink("/Users/larry/.mblaze/cur\0", 0x1097C0F40, 0x3FF)		 = 59 0
readlink("/Users/larry/.mblaze/cur\0", 0x1097C0F40, 0x3FF)		 = 59 0
open(".mail/inbox//cur/1490462878.95690_0.sutro.larryhynes.com:2,\0", 0x0, 0x0)		 = 3 0
fstat64(0x3, 0x7FFF56446510, 0x0)		 = 0 0
read(0x3, "Return-Path: [email protected]\nDelivered-To: [email protected]\nReceived: from forward4m.xxx.net (forward4m.xxx.net [1.2.3.4])\n\tby yyy.com (OpenSMTPD) with ESMTPS id 1f53a4de (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO", 0x14E7A)		 = 85626 0
close(0x3)		 = 0 0
getrlimit(0x1008, 0x7FFF564463B0, 0x14E7A)		 = 0 0
fstat64(0x1, 0x7FFF56446448, 0x14E7A)		 = 0 0
pipe(0x1, 0x7FFF56446448, 0x14E7A)		 = 3 0
pipe(0x1, 0x7FFF56446448, 0x14E7A)		 = 5 0
fork()		 = 36803 0
close(0x3)		 = 0 0
close(0x6)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
write(0x4, "<div>This is a test, with some <strong>html</strong> formatting, and an attachment.</div>ZUCS01GOrZ\ntJZDL2Kh4RrqFtcyrZVVe7QSge99pcZ46HpzZEWbd4cr1pq+LY3N1xBWlYN4upw0irO0CoMd0VY6\nWO4mmwBxxtA7ME8y+sodLvHc3n2s8bFxH/1JRNWdTFHSV7O7sjBt/kTR6MxvHg8nGwEIA/7gtscu\nqT", 0x59)		 = 89 0
close(0x4)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
dtrace: 151721 dynamic variable drops with non-empty dirty list
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "This is a test, with some html formatting, and an attachment.\n\n\n\0", 0x200)		 = 64 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "\0", 0x200)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "\0", 0x200)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "\0", 0x200)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "\0", 0x200)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "\0", 0x200)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "\0", 0x200)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "\0", 0x200)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "\0", 0x200)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "\0", 0x200)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "\0", 0x200)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "\0", 0x200)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "\0", 0x200)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "\0", 0x200)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "\0", 0x200)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "\0", 0x200)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "\0", 0x200)		 = 0 0
poll(0x7FFF564453E0, 0x2, 0xFFFFFFFF)		 = 1 0
read(0x5, "\0", 0x200)		 = 0 0

(it just continues like this until abort.)

add "print" operation to msed

To quickly get the value of a header it would be very helpful to have msed /header/p. The best other way to do this that I could come up with is mshow -q -L | grep \^header: | cut blablabla, and that's very annoying to work with interactively.

bash's builtin echo doesn't seem to like -n, in mcom

/bin/sh on my machine is linked to bash. In a somewhat bizarre twist, it's builtin echo doesn't seem to like -n, which leads to weird output for mcom, like -n To:.

$ /bin/sh

$ echo $BASH_VERSION
3.2.57(1)-release

$ echo -n foo
-n foo

$ builtin echo -n foo
-n foo

$ /bin/echo -n foo
foo

I really don't know if this is a bash issue, a bash as /bin/sh issue, or a there's pixies in my computer issue. The following takes a blunt instrument to the problem, and replaces echo with /bin/echo.

diff --git a/mcom b/mcom
index 82920dd..6e52f91 100755
--- a/mcom
+++ b/mcom
@@ -14,7 +14,7 @@ msgid() {
 }
 
 msgdate() {
-	echo -n "Date: "
+	/bin/echo -n "Date: "
 	mdate
 }
 
@@ -44,7 +44,7 @@ fi
 {
 	case "$0" in
 	*mcom*)
-		echo -n "To: "
+		/bin/echo -n "To: "
 		printf '%s\n' "$@" | commajoin
 		echo "Cc: "
 		echo "Bcc: "
@@ -75,7 +75,7 @@ fi
 		cat "$MBLAZE/headers" 2>/dev/null
 		mid=$(mhdr -h message-id "$1")
 		if [ "$mid" ]; then
-			echo -n "References:"
+			/bin/echo -n "References:"
 			{
 				mhdr -h references "$1"
 				printf "%s\n" "$mid"
@@ -180,7 +180,7 @@ while :; do
 		c=
 		;;
 	*)
-		echo -n "What now? ([s]end, [c]ancel, [d]elete, [e]dit, [m]ime) "
+		/bin/echo -n "What now? ([s]end, [c]ancel, [d]elete, [e]dit, [m]ime) "
 		read -r c
 		;;
 	esac

How to extract all attachments from an email?

Yep I can't seem to find that one out. Read mhdr, msed and alike manuals already.

mrefile: preserve file times

When I use mrefile(1) to move a message to a different folder in my mail structure, the resulting file has a fresh modification time. This mtime ends up getting used by isync's mbsync(1) when sending the message back to my mail host with an IMAP APPEND with an explicit internal time. The result is a refiled message on the IMAP server with a fresh internal time, as opposed to the original time the message was received.

mdeliver -M extracts the Date: from each message to use as the mtime of the resulting file. mutt(1) appears to have similar behavior when copying messages. I propose mrefile(1) should behave this way as well, or optionally behave this way, to accurately perform the "move messages between folders" task.

(It's late and I am unable to think through whether this should really be the job of mrefile(1) or if mbsync(1) using APPEND instead of somehow using COPY is a bug.)

Option for mcom/mrep/mfwd/mbnc default action

It would be useful to allow default actions to mcom (and alike) in case you want to create an automated message and not view it.

Trailing slash on maildir confuses %F in mscan format

Hi

When including %Fin the mscan format string, including a trailing slash on the maildir makes mscan list an empty maildir:

$ mlist mail/obsd/ | tail -1 | mscan
 .       Wed  22:07 Reyk Floeter        Re: Arch and vmd
1 mails scanned

$ mlist mail/obsd | tail -1 | mscan
 .      obsd Wed  22:07 Reyk Floeter        Re: Arch and vmd
1 mails scanned

Scan-Format: %c%u%r %-3n %F %10d %17f %t %2i%s

 $ mlist mail/obsd/ | tail -1
mail/obsd//cur/1493241609.7408_0.sutro.larryhynes.com:2,T

I'm not going to pretend to understand the logic for %F in mscan.c, but I wonder if we could handle instances of // in a path spec. as something other than "". (Or, to come at it from another angle, I wonder does mlist have to add a / to arguments passed to it, if they already end in /.)

magrep crash with base64 encoded messages

This is on OpenBSD:

$ magrep /:test ./examplemsg                                                                
Segmentation fault (core dumped)

#0  strlen () at /usr/src/lib/libc/arch/amd64/string/strlen.S:124
#1  0x00000c8211b8502b in regexec (preg=Variable "preg" is not available.
) at engine.c:150
#2  0x00000c800e500bfb in match (file=0x7f7ffffdc406 "./examplemsg", hdr=0xc800e606a3d "/", 
    s=0xc830d9797c0 "this is a test\r\nthis is a test\r\nthis is a test\r\nthis is a test\r\nthis is a test\r\nthis is a test\r\nthis is a test\r\nthis is a test\r\nthis is a test\r\nthis is a test\r\nthis is a test\r\nthis is a test\r\nthis is "...) at magrep.c:49
#3  0x00000c800e5010d9 in match_part (depth=Variable "depth" is not available.
) at magrep.c:94
#4  0x00000c800e505118 in blaze822_walk_mime (msg=0xc8273d81740, depth=0, visit=0xc800e501020 <match_part>) at rfc2045.c:185
#5  0x00000c800e500fcd in magrep (file=0x7f7ffffdc406 "./examplemsg") at magrep.c:129
#6  0x00000c800e504143 in blaze822_loop (argc=1, argv=Variable "argv" is not available.
) at seq.c:481
#7  0x00000c800e500a5d in main (argc=1, argv=0x7f7ffffdc2a8) at magrep.c:203

Example message is here.

It looks like the decoded base64 string isn't null terminated:

(gdb) up 2
[...]
(gdb) print s[2111]
$1 = 10 '\n'
(gdb) print s[2112]
Cannot access memory at address 0xc830d97a000

[mcolor] Rework color used to match themes

On my custom terminal theme the mcolor command looks bad because it uses colors outside the customized range.

An example can be found here:
https://i.imgur.com/aENRzT9.png

I've defined colors like this:
https://github.com/chriskempson/base16-shell/blob/master/scripts/base16-default-dark.sh

New script: mmatt

Sometimes I send a ton of attachments per mail, mostly for holiday pictures or important documents.
I do this by preparing a file with a list of all attachments that I want to send and then run this little self-written script that just passes them to mcom (named it mmatt for [m]blaze [m]ultiple [att]achments).

#!/usr/bin/env sh

test -f "${1}" || exit 1
at=$(awk '{print "-attach "$1}' "${1}" | tr '\n' ' ')
mcom ${at}

If too simple/useless feel free to close :)

Emails with large headers crashes mscan

It looks like any emails with more than 4096 bytes of headers causes mscan to segfault. I have a lot of mail with many "Received" headers and large DKIM keys which go over this limit.

Example crash:

Core was generated by `mscan'.
Program terminated with signal 11, Segmentation fault.
[...]
#0  0x0000153f14203b4c in mymemmem (h0=Variable "h0" is not available.
) at mymemmem.c:32
32              for (h++, k--; k; k--, hw = hw<<8 | *++h)
(gdb) bt
#0  0x0000153f14203b4c in mymemmem (h0=Variable "h0" is not available.
) at mymemmem.c:32
#1  0x0000153f14202456 in blaze822 (file=Variable "file" is not available.
) at blaze822.c:361
#2  0x0000153f142013ba in oneline (file=0x1541491dab80 "/tmp/boom.eml")
    at mscan.c:284
#3  0x0000153f14204b9b in blaze822_loop (argc=0, argv=0x1541bda97000,
    cb=0x153f14201360 <oneline>) at seq.c:510
#4  0x0000153f14200dc2 in main (argc=0, argv=0x7f7ffffed768) at mscan.c:565

Where "boom.eml" is a file with the line:

Testing: 1234567890 1234567890 1234567890 1234567890 1234567890

repeated 64 times

document use of MAILFILTER environment var in mshow

Getting mshow -x to use filename / name

Most of the time (like, all of the time) mshow -x msg part saves attachment<part>. I have seen it use the "filename" or "name" from Content-Disposition or Content-Type, but I can't make it do so reliably. (A diagnostic nightmare, in other words 😄)

It's not a big deal (and I ain't complaining - big mblaze fan, me!), insofar as I'm training myself to mv $(mshow -x msg part) ~/foo.mime.type, but I'd love to find out what it is in my local setup that's making extract_mime() in mshow.c go straight to

else {
    snprintf(buf, sizeof buf,
    "attachment%d", mimecount);

The following was tested on a simple test message (copy at the end of this), as saved in my outbox. (I've tested the same message as it arrives at my mail server, and after fdm fetches it locally, with the same results.)

$ mshow -t ./testmessage
./testmessage
  1: multipart/mixed size=4807
    2: text/plain size=17
    3: image/png size=3260

$ mshow -x ./testmessage 3
attachment3

Any pointers or insights would be most welcome!

To: [email protected]
Cc: 
Bcc: 
Subject: Test
From: "Larry Hynes" <[email protected]>
Message-Id: <[email protected]>
Date: Sat, 27 May 2017 13:11:09 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_05d52f704d6b3c9a4c84aadc_=_"

This is a multipart message in MIME format.

------_=_05d52f704d6b3c9a4c84aadc_=_
Content-Type: text/plain; charset=UTF-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

This is a test.


------_=_05d52f704d6b3c9a4c84aadc_=_
Content-Disposition: attachment; filename="dot.png"
Content-Type: image/png
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAAkAAAAHCAYAAADam2dgAAAKu2lDQ1BJQ0MgUHJvZmlsZQAASImV
lwdQk9kWx+/3pYeEFggdQm+C9Cq9hiJIB1EJSQihhJCCil0RV3AtiIiAuqIrIAquSl1UxIKFRVAB
+4IsAsq6WFAUlfcBj/Dem7fz5v1n7uSXM+c7Oefm3pn/BwBphMHnp8GyAKTzRIIwP09aTGwcDTcA
IIADVKAAiAymkO8RGhoE/lYfe5FsRPfNZmr9fd5/lRyLLWQCAIUinMgSMtMRvoCsTiZfIAIAlYPE
dVeL+DNcibCCAGkQ4ZYZ5sxx1wwnzvEfszkRYV4ITwKAJzEYAg4AJDQSp2UxOUgdkh7CFjwWl4dw
BMKuzGQGC+FChBelp2fMcCvCRon/UofzbzUTJTUZDI6E52aZFd6bK+SnMdb+n9vxv5WeJp7/DR1k
kZIF/mHIpwGyZ5WpGYES5iUuDZlnLms2f5aTxf6R88wUesXNM4vhHTjP4tRIj3lmCBae5YroEfMs
yAiT1GcLfcIl9dn0IEkPaUslnMT1pc9zdnJE9DxncaOWzrMwNTxwIcdLEheIwyQ9Jwl8JTOmCxd6
YzIWehAlR/gv9BYj6YHF9vaRxHmRkny+yFNSk58WKslnp/lJ4sKscMmzIuSAzXMKIyB0oU6oZH9A
BEgGYsADLMAGApAIMkAaEAEa8AZcIAR85BsDIMdDxF4jmhnCK4O/VsDlJItoHsgtYtPoPKb5IpqV
haU9ADN3cu4vf0+dvWsQ9fZCLLMVAMc8JMhZiDF0AWh6CQDl40JM9x1yXPYCcLGLKRZkzcVmji3A
ACKQQe66CtAEusAImAErYAecgTvwAQEgBJkkFqwETGSedGSS1WA92AJyQT7YCw6AEnAUHAeV4Aw4
BxpAC7gCboA7oAv0gCegHwyB12AcfARTEAThIDJEgVQgLUgfMoWsIAfIFfKBgqAwKBZKgDgQDxJD
66FtUD5UAJVAx6Aq6BeoCboC3YK6oUfQADQKvYO+wCiYBCvAGrABvBh2gD3gQDgCXgFz4Ew4G86B
d8PFcDl8Gq6Hr8B34B64H34NT6AASgpFRWmjzFAOKC9UCCoOlYQSoDai8lBFqHJUDaoZ1Y66j+pH
jaE+o7FoCpqGNkM7o/3RkWgmOhO9Eb0LXYKuRNejr6HvowfQ4+jvGDJGHWOKccLQMTEYDmY1JhdT
hDmJqcNcx/RghjAfsVgsFWuItcf6Y2OxKdh12F3Yw9habCu2GzuIncDhcCo4U5wLLgTHwIlwubhD
uNO4y7h7uCHcJF4Kr4W3wvvi4/A8/FZ8Ef4U/hL+Hn4YP0WQJegTnAghBBZhLWEP4QShmXCXMESY
IsoRDYkuxAhiCnELsZhYQ7xOfEp8LyUlpSPlKLVMiiu1WapY6qzUTakBqc8keZIJyYsUTxKTdpMq
SK2kR6T3ZDLZgOxOjiOLyLvJVeSr5OfkSWmKtLk0XZolvUm6VLpe+p70GxmCjL6Mh8xKmWyZIpnz
MndlxmQJsgayXrIM2Y2ypbJNsn2yE3IUOUu5ELl0uV1yp+RuyY3I4+QN5H3kWfI58sflr8oPUlAU
XYoXhUnZRjlBuU4ZUsAqGCrQFVIU8hXOKHQqjCvKK9ooRimuUSxVvKjYT0VRDah0ahp1D/UctZf6
RUlDyUOJrbRTqUbpntInZTVld2W2cp5yrXKP8hcVmoqPSqrKPpUGlWeqaFUT1WWqq1WPqF5XHVNT
UHNWY6rlqZ1Te6wOq5uoh6mvUz+u3qE+oaGp4afB1zikcVVjTJOq6a6ZolmoeUlzVIui5arF1SrU
uqz1iqZI86Cl0Ypp12jj2ura/tpi7WPandpTOoY6kTpbdWp1nukSdR10k3QLddt0x/W09IL11utV
6z3WJ+g76CfrH9Rv1/9kYGgQbbDDoMFgxFDZkG6YbVht+NSIbORmlGlUbvTAGGvsYJxqfNi4ywQ2
sTVJNik1uWsKm9qZck0Pm3YvwixyXMRbVL6oz4xk5mGWZVZtNmBONQ8y32reYP5msd7iuMX7Frcv
/m5ha5FmccLiiaW8ZYDlVstmy3dWJlZMq1KrB9Zka1/rTdaN1m9tTG3YNkdsHtpSbINtd9i22X6z
s7cT2NXYjdrr2SfYl9n3OSg4hDrscrjpiHH0dNzk2OL42cnOSeR0zukvZzPnVOdTziNLDJewl5xY
Muii48JwOebS70pzTXD9ybXfTduN4Vbu9sJd153lftJ92MPYI8XjtMcbTwtPgWed5ycvJ68NXq3e
KG8/7zzvTh95n0ifEp/nvjq+HN9q33E/W791fq3+GP9A/33+fXQNOpNeRR8PsA/YEHAtkBQYHlgS
+CLIJEgQ1BwMBwcE7w9+ulR/KW9pQwgIoYfsD3kWahiaGfrrMuyy0GWly16GWYatD2sPp4SvCj8V
/jHCM2JPxJNIo0hxZFuUTFR8VFXUp2jv6ILo/pjFMRti7sSqxnJjG+NwcVFxJ+MmlvssP7B8KN42
Pje+d4XhijUrbq1UXZm28uIqmVWMVecTMAnRCacSvjJCGOWMiUR6YlniONOLeZD5muXOKmSNsl3Y
BezhJJekgqQRjgtnP2c02S25KHmM68Ut4b5N8U85mvIpNSS1InU6LTqtNh2fnpDexJPnpfKuZWhm
rMno5pvyc/n9mU6ZBzLHBYGCk0JIuELYKFJAzE+H2Ei8XTyQ5ZpVmjW5Omr1+TVya3hrOtaarN25
djjbN/vndeh1zHVt67XXb1k/sMFjw7GN0MbEjW2bdDflbBra7Le5cgtxS+qW37ZabC3Y+mFb9Lbm
HI2czTmD2/22V+dK5wpy+3Y47zj6A/oH7g+dO613Htr5PY+VdzvfIr8o/+su5q7bP1r+WPzj9O6k
3Z177PYc2Yvdy9vbu89tX2WBXEF2weD+4P31hbTCvMIPB1YduFVkU3T0IPGg+GB/cVBx4yG9Q3sP
fS1JLukp9SytLVMv21n26TDr8L0j7kdqjmoczT/65SfuTw+P+R2rLzcoLzqOPZ51/OWJqBPtPzv8
XHVS9WT+yW8VvIr+yrDKa1X2VVWn1E/tqYarxdWjp+NPd53xPtNYY1ZzrJZam38WnBWfffVLwi+9
5wLPtZ13OF9zQf9CWR2lLq8eql9bP96Q3NDfGNvY3RTQ1Nbs3Fz3q/mvFS3aLaUXFS/uuUS8lHNp
+nL25YlWfuvYFc6VwbZVbU+uxlx9cG3Ztc7rgddv3vC9cbXdo/3yTZebLbecbjXddrjdcMfuTn2H
bUfdb7a/1XXaddbftb/b2OXY1dy9pPvSPbd7V+5737/xgP7gTs/Snu7eyN6HffF9/Q9ZD0cepT16
+zjr8dSTzU8xT/OeyT4req7+vPx3499r++36Lw54D3S8CH/xZJA5+PoP4R9fh3Jekl8WDWsNV41Y
jbSM+o52vVr+aug1//XUWO6fcn+WvTF6c+Ev9786xmPGh94K3k6/2/Ve5X3FB5sPbROhE88/pn+c
+pQ3qTJZ+dnhc/uX6C/DU6u/4r4WfzP+1vw98PvT6fTpaT5DwJi1AihkwUlJALyrAIAci3gHxFcT
pec886ygOZ8/S+DveM5Xz8oOgAp3ACI3AxCEeJQjyNLfPOetZyxThDuAra0l658SJllbzdUiIc4T
Mzk9/V4DAFwzAN8E09NTh6env51Amn0EQGvmnFefERZ5gykwhJEJbt6+KwP+Q/8AdSgKP6vTg3QA
AAGZaVRYdFhNTDpjb20uYWRvYmUueG1wAAAAAAA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5z
Om1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA1LjQuMCI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0i
aHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6
RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOmV4aWY9Imh0dHA6Ly9u
cy5hZG9iZS5jb20vZXhpZi8xLjAvIj4KICAgICAgICAgPGV4aWY6UGl4ZWxYRGltZW5zaW9uPjk8
L2V4aWY6UGl4ZWxYRGltZW5zaW9uPgogICAgICAgICA8ZXhpZjpQaXhlbFlEaW1lbnNpb24+Nzwv
ZXhpZjpQaXhlbFlEaW1lbnNpb24+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpS
REY+CjwveDp4bXBtZXRhPgqKwzUtAAAAF0lEQVQYGWNk0Db7z0AAMBGQB0sPWUUAZ1MBbvPPlNMA
AAAASUVORK5CYII=

------_=_05d52f704d6b3c9a4c84aadc_=_--

perror on mpick

I get this error while I run this command:

$ mlist INBOX | mpick from '~~~' 'amnesty' | mscan
mpick: parse error: invalid string operator at '.addr == 's''
0 mails scanned

I also get the same error on other directories (with filtered mails).

Now how can I help with this?

Use XDG_USER_DIRS when possible?

FreeDesktop.org propose a standard location for configuration files in ~/.config rather than right away in the $HOME directory.

I like to have configuration in some "config" directory (Rob Pike on dotfiles).

From mblaze(1), I saw ~/.mblaze as a location for configuration files.

Are you willing to change for ~/.config/mblaze ?

Document empty line requirement between headers and body

This way users won't be confused when they don't know how rfc 822 works.

mshow -x doesn't decode quoted-words

Specifying address(es) not to be cc'ed

This is not an issue, per se, it's a 'thinking out loud' exercise; apologies if it gets 'rambly'. It's also not a 'feature request', as I think all the tools are there to handle this already.

In order not to be cc'ed on every mail that I reply to, I've modified mcom a wee bit, using sed to remove my primary address in mcoms printf Cc:... line, like so:

printf 'Cc: %s\n' "$(mhdr -d -A -h to:cc: "$1" | sed '/[email protected]/d' | commajoin)

And that is, honestly, as much of a "feature" as I want here and I'm quite happy to stick with this local change. I do wonder, though, if it could be implemented with a Nocc: [email protected] header (or headers) in ~/.mblaze/profile. (Using the full form of the From: header probably won't work, as some people will have included me as, for instance, "Hynes Larry" <[email protected]>", where my From: is "Larry Hynes" <[email protected]>.)

What should I be doing here, or what are other people doing? Is calling msed from mcom an option? I mean, I was just manually deleting my address from the Cc: line in the message draft, but then I'd forget every now and then, so my current solution is a bit more permanent and a bit more convenient for me.

[mlist] Use $MAIL variable when no path is specified

I'd love to see some $MAIL usage if I don't pass a folder to mlist.

Other commands could maybe also benefit from this.