When parsing address header fields, the field charset is automatically
decoded to UTF-8. If the charset is unknown, use the raw field value.
Fixes: https://todo.sr.ht/~rjarry/aerc/91
Signed-off-by: Koni Marti <koni.marti@gmail.com>
Tested-by: Tim Culverhouse <tim@timculverhouse.com>
Do not throw an error when the charset is unknown; the message entity
can still be read, but log the error instead.
Reported-by: falsifian
Signed-off-by: Koni Marti <koni.marti@gmail.com>
Acked-by: Robin Jarry <robin@jarry.cc>
When there is no Date header in a message, aerc falls back to the
Received header and tries to extract an rfc1123z date from it
(introduced in commit d1600e46). The current regex for extracting the
date incorrectly allows for trailing whitespace, causing time.Parse() to
fail inside of parseReceivedHeader(). As a result, the message's date is
shown as "???????????????????" in the message list and as
"0000-12-31 07:03 PM" in the message view (the latter is likely related
to the zero value of time.Time).
Steps to reproduce:
1) Send yourself a message with no Date header, e.g. with msmtp:
printf 'Subject: foo bar\n\nbody text\n' | msmtp --set-date-header=off me@example.com
2) Note the message's displayed date in aerc's message list and message
view.
Signed-off-by: Thomas Faughnan <tom@tjf.sh>
Acked-by: Robin Jarry <robin@jarry.cc>
Fix the following test failures:
FAIL: TestMessageInfoHandledError (0.00s)
parse_test.go:53: could not parse envelope: date parsing failed:
unrecognized date format:
FAIL: TestReader (0.07s)
gpg_test.go:27: using GNUPGHOME = /tmp/TestReader2384941142/001
reader_test.go:108: Test case: Invalid Signature
reader_test.go:112: gpg.Read() = gpgmail: failed to read PGP
message: gpg: failed to run verification: exit status 1
Fixes: 5ca6022d00 ("lint: ensure errors are at least logged (errcheck)")
Fixes: 70bfcfef42 ("lint: work nicely with wrapped errors (errorlint)")
Signed-off-by: Robin Jarry <robin@jarry.cc>
Signed-off-by: Moritz Poldrack <moritz@poldrack.dev>
Error wrapping as introduced in Go 1.13 adds some additional logic to
use for comparing errors and adding information to it.
Signed-off-by: Moritz Poldrack <moritz@poldrack.dev>
Acked-by: Robin Jarry <robin@jarry.cc>
If an error occurs when parsing the content-type, check if the
content-type is quoted; if so, remove quotes. If this is not the case,
then return a text/plain content-type as a sane fallback option, so that
the message can be at least viewed in plaintext.
Fixes: https://todo.sr.ht/~rjarry/aerc/44
Signed-off-by: Koni Marti <koni.marti@gmail.com>
Acked-by: Robin Jarry <robin@jarry.cc>
Ensure CRLF line endings in the pgpmail reader. Fix the pgp signature
verification for maildir and notmuch.
These backends do not return the full message body with CRLF
line endings. But the accepted OpenPGP convention is for signed data to
end with a <CR><LF> sequence (see RFC3156).
If this is not the case the signed and transmitted data are considered
not the same and thus signature verification fails.
Link: https://datatracker.ietf.org/doc/html/rfc3156
Reported-by: Tim Culverhouse <tim@timculverhouse.com>
Signed-off-by: Koni Marti <koni.marti@gmail.com>
Tested-by: Tim Culverhouse <tim@timculverhouse.com>
This commit fixes all occurrences of the abovementioned lint-error in
the codebase.
Signed-off-by: Moritz Poldrack <git@moritz.sh>
Acked-by: Robin Jarry <robin@jarry.cc>
Previously, Message.NewReader returned the wrapped buffered reader
without a reference to the opened file, so the files descriptors
were left unclosed after reading. Now, the file reader is returned
directly and closed on the call site. Buffering is not needed here
because it is an implementation detail of go-message.
Fixes: https://todo.sr.ht/~rjarry/aerc/9
We made a new type out of go-message/mail.Address without any real reason.
This suddenly made it necessary to convert from one to the other without actually
having any benefit whatsoever.
This commit gets rid of the additional type
This change handles message parse errors by printing the error when the
user tries to view the message. Specifically only handling unknown
charset errors in this patch, but there are many types of invalid
messages that can be handled in this way.
aerc currently leaves certain messages in the msglist in the pending
(spinner) state, and I'm unable to view or modify the message. aerc also
only prints parse errors with message when they are initially loaded.
This UX is a little better, because you can still see the header info
about the message, and if you try to view it, you will see the specific
error.
This allows us to hook into the std libs implementation of parsing related stuff.
For this, we need to get rid of the distinction between a mailbox and a host
to just a single "address" field.
However this is already the common case. All but one users immediately
concatenated the mbox/domain to a single address.
So this in effects makes it simpler for most cases and we simply do the
transformation in the special case.
If a message date would fail to parse, the worker would never receive
the MessageInfo it asked for, and so it wouldn't display the message.
The problem is the spec for date formats is too lax, so trying to ensure
we can parse every weird date format out there is not a strategy we want
to pursue. On the other hand, preventing the user from reading and
working with a message due to the error format is also not a solution.
The maildir and notmuch workers will now fallback to the internal date, which
is based on the received header if we can't parse the format of the Date header.
The UI will also fallback to the received header whenever the date header can't
be parsed.
This patch is based on the work done by Lyudmil Angelov <lyudmilangelov@gmail.com>
But tries to handle a parsing error a bit more gracefully instead of just returning
the zero date.
Aerc usually used the path []int{1} if it didn't know what the proper path is.
However this only works for multipart messages and breaks if it isn't one.
This patch removes all the hard coding and extracts the necessary helpers to lib.
When message dates failed to parse, the error displayed would try to
include the time object it failed to obtain, which would display as
something like 0001-01-01 00:00:00 UTC, which isn't of much help.
Instead, display the text we were trying to parse into a date, which
makes the problem easier to debug.
Things like FetchEntityPartReader etc can be reused by most workers
working with raw email files from disk (or any reader for that matter).
This patch extract that common functionality in a separate package.
