[LINK] RFI: Thunderbird

Craig Sanders cas at taz.net.au
Thu Oct 11 14:32:09 AEDT 2018

On Wed, Oct 10, 2018 at 05:17:13PM +1100, Roger Clarke wrote:
> (1) Getting access to attachments (THE CURRENT PARTY-STOPPER)
>     Thunderbird is just as bad as Apple Mail, in that all attachments
>     are buried in huge, deep-nested directories, still encoded.
>     Searches on a known filename don't find it, in either Spotlight or
>     EasyFind. so it's impossible to locate received files!
>     ('Someone sent you a file called squiggle.xyz.  Did you get it?')

1. thunderbird does have pretty good search capabilities.  You could use those
if you need to find a file attached to an email.

2. I have no idea if it's any good or not, but google tells me
that there's an Attachment Search Tab plugin for Thunderbird at

The description says: "an extension that allows to search an attachment in one
or more folders.  To use it, click on Tools (in the menu bar) --> Attachment
search. latest: 0.4.3 (TB - compatible 3.1 or higher)"

There's a bunch of other TB plugins there, and the author seems to be actively
updating them.

3. I don't think this will ever be truly "solved" in any mail client.

Mostly because attachments are not really files (at least not until you save
them).  They're just more text in the message.  They might be presented to you
in the mail client as if they're separte files, but they're not.

These days they're almost all base64-encoded text, with a mime attachment
header, included in the text of the message.  This is done because email is
still mostly a 7-bit ascii format, and to prevent the binary data in the file
from being interpreted as control-codes by either the mail client or the mail
servers that the message passes through.

You sometimes still see uuencoded files embedded in emails. Similar to base64,
but obsolete and rarely used these days. ditto for the ancient binhex format
that used to be common on Macs in the 80s and 90s. Both of these formats are
typically embedded in the message without a mime type header, so mail clients
have no way of knowing where attachments begin and end within the text.  Same
idea, earlier more primitive implementation.

BTW, mime attachments of base64-encoded files are typically around 37% larger
than the original file they're encoding.  This is worth knowing if you use a
mail server with a message size limit - if it's set to say 10MB maximum, that
means the largest attachment you can include is around 7.2MB (depending on how
much text is in the message it's attached to). For more details about base64,
see https://en.wikipedia.org/wiki/Base64

Anyway, it would be possible to write a plugin that automatically saved
attachments using the filename specified in the attachment metadata (note: a
filename is not mandatory there)....but what should it do when multiple people
send you different files with the same filename?

the obvious solution is to auto-save it as "sender-address.filename"
but then you have the problem of deciding what to do if one email
address sends you multiple versions with the same filename.  So use

The bigger problem is that auto-saving opens up some security risks.  If the
plugin blindly trusts the attachment's filename, it's theoretically possible
for a filename to be constructed by the sender that causes existing files to
be over-written. i.e. the usual "don't trust data from untrusted sources like
the internet" problem.

If it doesn't trust the attachment's filename, then every attachment received
will cause the plugin to annoy the user with a demand for a filename (i.e.
pop up a file save dialog).  More annoying but no more useful than just doing
nothing with an attachment unless the user chooses to save it.

Security is probably the real reason why this won't ever be solved. it's a
never-ending conflict escalation, and the attackers are always ahead.  Much
easier and safer to leave it up to the user to decide if they want to save an
attachment and where and with what name.

Probably the only safe way to do it is for a plugin to auto-save files to a
particular subdirectory, using numbered filenames.  It would also have to
maintain a database of relevant info like sender address, date, time, mime
filename, etc.  This would not, of course, solve your problem of wanting
to search by filename on the desktop - you'd have to search the database
which would tell you the actual filename on the system.  I guess a Spotlight
extension could be written to do that.

Thunderbird is doing something similar to this when it stores attachments
"buried in huge, deep-nested directories, still encoded."  Maybe someone has
written a plugin for Spotlight or EasyFind to search Thunderbird's email &
attachment metadata database.  (I don't know if plugins are possible for these
programs. I don't use either of them)


craig sanders <cas at taz.net.au>

More information about the Link mailing list