leahneukirchen / mblaze Goto Github PK
View Code? Open in Web Editor NEWUnix utilities to deal with Maildir
License: Other
Unix utilities to deal with Maildir
License: Other
MBLAZE(7) Miscellaneous Information Manual MBLAZE(7) NAME mblaze – introduction to the mblaze message system DESCRIPTION The mblaze message system is a set of Unix utilities for processing and interacting with mail messages which are stored in maildir folders. Its design is roughly inspired by MH, the RAND Message Handling System, but it is a complete implementation from scratch. mblaze consists of these Unix utilities that each do one job: maddr(1) extract mail addresses from messages magrep(1) search messages matching a pattern mbnc(1) bounce messages mcom(1) compose and send messages mdeliver(1) deliver messages or import mbox file mdirs(1) list maildir folders, recursively mexport(1) export messages as mbox file mflag(1) manipulate maildir message flags mflow(1) reflow format=flowed plain text messages mfwd(1) forward messages mgenmid(1) generate a Message-ID mhdr(1) print message headers minc(1) incorporate new messages mless(1) conveniently read messages in less(1) mlist(1) list and filter messages mmime(1) create MIME messages mmkdir(1) create new maildir folders mpick(1) advanced message filter mrefile(1) move or copy messages between maildir folders mrep(1) reply to messages mscan(1) generate one-line message summaries msed(1) manipulate message headers mseq(1) manipulate message sequences mshow(1) render messages and extract MIME parts msort(1) sort messages mthread(1) arrange messages into discussions mblaze is a classic command line MUA and has no features for receiving or transferring messages; you can operate on messages in a local maildir spool, or fetch your messages using fdm(1), getmail(1), offlineimap(1), or similar utilities, and send it using dma(8), msmtp(1), sendmail(8), as provided by OpenSMTPD, Postfix, or similar. mblaze operates directly on maildir folders and doesn't use its own caches or databases. There is no setup needed for many uses. All utilities have been written with performance in mind. Enumeration of all messages in a maildir is avoided unless necessary, and then optimized to limit syscalls. Parsing message metadata is optimized to limit I/O requests. Initial operations on a large maildir may feel slow, but as soon as they are in the file system cache, everything is blazingly fast. The utilities are written to be memory efficient (i.e. not wasteful), but whole messages are assumed to fit into RAM easily (one at a time). mblaze has been written from scratch and is now well tested, but it is not 100% RFC-conforming (which is neither worth it, nor desirable). There may be issues with very old, nonconforming, messages. mblaze is written in portable C, using only POSIX functions (apart from a tiny Linux-only optimization), and has no external dependencies. It supports MIME and more than 7-bit messages (everything the host iconv(3) can decode). It assumes you work in a UTF-8 environment. mblaze works well with other Unix utilities such as mairix(1), mu(1), or offlineimap(1). EXAMPLES mblaze utilities are designed to be composed together in a pipe. They are suitable for interactive use and for scripting, and integrate well into a Unix workflow. For example, you could decide you want to look at all unseen messages in your INBOX, oldest first. mlist -s ~/Maildir/INBOX | msort -d | mscan To operate on a set of messages in multiple steps, you can save it as a sequence, e.g. add a call to ‘mseq -S’ to the above command: mlist -s ~/Maildir/INBOX | msort -d | mseq -S | mscan Now mscan will show message numbers and you could look at the first five messages at once, for example: mshow 1:5 Likewise, you could decide to incorporate (by moving from new to cur) all new messages in all folders, thread it and look at it interactively: mdirs ~/Maildir | xargs minc | mthread | mless Or you could list the attachments of the 20 largest messages in your INBOX: mlist ~/Maildir/INBOX | msort -S | tail -20 | mshow -t Or apply the patches from the current message: mshow -O. '*.diff' | patch As usual with pipes, the sky is the limit. CONCEPTS mblaze deals with messages (which are files), folders (which are maildir folders), sequences (which are newline-separated lists of messages, possibly saved on disk in ${MBLAZE:-$HOME/.mblaze}/seq), and the current message (kept as a symlink in ${MBLAZE:-$HOME/.mblaze}/cur). Messages in the saved sequence can be referred to using special syntax as explained in mmsg(7). Many utilities have a default behavior when used interactively from a terminal (e.g. operate on the current message or the current sequence). For scripting, you must make these arguments explicit. For configuration, see mblaze-profile(5). SEE ALSO mailx(1), mblaze-profile(5), nmh(7) AUTHORS Leah Neukirchen <[email protected]> There is a mailing list available at [email protected] (to subscribe, send a message to [email protected]); archives are available at https://inbox.vuxu.org/mblaze/. There also is an IRC channel #vuxu on irc.libera.chat. Please report security-related bugs directly to the author. LICENSE mblaze is in the public domain. To the extent possible under law, the creator of this work has waived all copyright and related or neighboring rights to this work. http://creativecommons.org/publicdomain/zero/1.0/ Void Linux January 18, 2020 Void Linux
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?
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.
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
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
.
mdir
act on current directory if no directory is given from the command line, as find
does ?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.
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.
mnext
and mprev
(likely as part of the mless
manpage)mdate
mquote
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
Similar problem as was in mlist:
term% minc mail/inbox/
mail/inbox//cur/1499794207.13948_0.localhost:2,
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.
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!
This just tests webhook integration.
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.
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;
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.
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.
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>""
.
#!/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}"
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.”
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
@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.
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
Yep I can't seem to find that one out. Read mhdr
, msed
and alike manuals already.
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]>
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!
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
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?
I'd really like to be able to customize the glyphs mscan uses for its output. See also: http://nerdfonts.com/
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
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?
This way users won't be confused when they don't know how rfc 822
works.
/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
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?
(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.)
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
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
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?
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).
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).
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.
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 mcom
s 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.
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 :)
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)
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
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
?
Hi
When including %F
in 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 /
.)
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_=_--
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.)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.