Remove "." from MimeSpecials (RFC2045 tspecials).
RFC2045 declares tspecials to not include a period. So encoding it
inside 2231 parameter values, or adding double quotes to MIME
parameter values (such as in Content-Type and Content-Disposition)
because of the presence of a period, while not illegal, is
unnecessary.
Ticket 491 reported a case where some Android clients were not
decoding the "." in an attachment filename extension for some unknown
reason. While this is clearly a bug in the Android client, it's also
true that the period need not have been encoded in the first place.
However, "." couldn't simply be removed from MIMESpecials, because it
was also used for RFC2047 encoding. RFC2047 encoded-words are used in
non-MIME headers, and cannot be double quoted.
Create a third "specials" list, RFC2047Specials, adding back in the
".", to keep RFC2047 encoding the same as it was. Add a comment as to
why it exists, to prevent someone from making the unfortunate mistake
of thinking it can just be changed back to use MIMESpecials.
Thanks to Peter Seiderer for reporting the issue and suggesting a fix,
which this patch is based upon.
Fix configure.ac AM_ICONV result checking.
--disable-iconv seeds the cache value variable, $am_cv_func_iconv, to
"no" to skip the test and disable iconv.
However, the result of an existing and *working* AM_ICONV test is
stored in $am_func_iconv. The call to AC_DEFINE(HAVE_ICONV) depends
on that variable.
Mutt was improperly checking $am_cv_func_iconv below.
In the event of an existing but broken iconv, this would result in
HAVE_ICONV being undefined, but mutt_idna.o being added to
MUTT_LIB_OBJECTS. This would cause both the stub functions in
mutt_idna.h and the full functions in mutt_idna.c to be defined,
giving a compilation error.
Thanks to @juanitotc for the bug report and helping to test the fix.
Add note about remote mailboxes to `$spoolfile` docs
Don't untag after edit-label.
Mutt is pretty consistent about NOT untagging automatically after an
operation. The only place where it does so is when deleting, but even
this is configurable via $delete_untag.
Add $smime_pkcs7_default_smime_type config option.
This works around Outlook sending application/pkcs7-mime ".p7m" parts
without a smime-type parameter.
Mutt previously hardcoded an assumption that these were SignedData to
work around an old Outlook book. However Outlook now appears to also
send EnvelopedData in this form.
automatic post-release commit for mutt-2.2.13
Update UPDATING file for 2.2.13 release.
Fix smtp client to respect $use_envelope_from option.
The code was only looking to see if $envelope_from_address had a
value, not if $use_envelope_from was set.
Add extra safety checks to make sure the mailbox value isn't NULL.
Fix smtp client $envelope_from_address possible dangling pointer.
If the account-hook invoked by mutt_conn_find() modifies
$envelope_from_address, envfrom could point no longer point to the
address.
Move the mutt_conn_find() before the code that determines the envelope
from address.
Use readline to overcome macOS input() restrictions
Under macOS, for a python script launched in a terminal, input() accepts only 1024 characters. In the authcode flow, the authorization code that is read by the call to input() around line 200 is longer than this and will be truncated, causing token retrieval to fail. Importing readline resolves this, allowing input() to accept a longer character string.
configure.ac: Fix ICONV_NONTRANS probe
The standard iconv function uses char ** even for its input argument.
With a const char ** argument, ICONV_NONTRANS is incorrectly set to 1
if the compiler produces an error for such incompatible pointer types.
Although as far as I can see, the only thing that accomplishes is
disabling an assert, so it probably does not matter much.
automatic post-release commit for mutt-2.2.12