The GifErrorString error is still there... $ make cc -std=gnu99 -fPIC -Wall -Wno-format-truncation -O2 -I/pjiu/include -c -o dgif_lib.o dgif_lib.c cc -std=gnu99 -fPIC -Wall -Wno-format-truncation -O2 -I/pjiu/include -c -o egif_lib.o egif_lib.c cc -std=gnu99 -fPIC -Wall -Wno-format-truncation -O2 -I/pjiu/include -c -o gifalloc.o gifalloc.c cc -std=gnu99 -fPIC -Wall -Wno-format-truncation -O2 -I/pjiu/include -c -o gif_err.o gif_err.c cc -std=gnu99 -fPIC -Wall -Wno-format-truncation -O2 -I/pjiu/include...
The GifErrorString error is still there... $ make cc -std=gnu99 -fPIC -Wall -Wno-format-truncation -O2 -I/pjiu/include -c -o dgif_lib.o dgif_lib.c cc -std=gnu99 -fPIC -Wall -Wno-format-truncation -O2 -I/pjiu/include -c -o egif_lib.o egif_lib.c cc -std=gnu99 -fPIC -Wall -Wno-format-truncation -O2 -I/pjiu/include -c -o gifalloc.o gifalloc.c cc -std=gnu99 -fPIC -Wall -Wno-format-truncation -O2 -I/pjiu/include -c -o gif_err.o gif_err.c cc -std=gnu99 -fPIC -Wall -Wno-format-truncation -O2 -I/pjiu/include...
The same error occurs if the email is decrypted manually using "Decrypt in folder". Its not the filter. But the filter seems to have another bug: Some e-mails with the structure described decrypt their content (the MIME part of the content, not the attachment) completely empty. This occurs sporadically and accidentally and the remedy is to simply decrypt this email manually (into a folder) again. This works always. I will try to get a log, but its not possible to enforce this bug. We are an authority...
Decrypted mail has empty Content-Type in the MIME part.
Decrypted mail has empty Content-Type in the MIME part.
Decrypted mail has empty Content-Type in the MIME part.
Enigmails filter actions forget selected mail folder names