Just following up on an older thread...
Tim:
>> You can try setting it to pass the file to xdg-open, and then
>> xdg-open will try opening the file in the right application for
>> what the file is. See if that changes anything.
Stephen Morris:
> To use xdg-open do I need to save the attachment first, or if not,
> when I am clicking on the attachment in the attachment bar at the
> bottom of the mail, to browse the attachment, how do I pass that into
> xdg-open?
xdg-open is a file handler program. Hand it a file, and it'll decide
what to do with it based on its own rules (determining the type of
file, and the appropriate/preferred application to read it), making it
a useful default to handle unknown (application/octet-stream) files
from the mail. In your mailer, you'd set it (xdg-open) as the default
program for such files, and/or any other files you'd like to palm off
to it. So, instead of setting acrobat in the attachment preferences,
you'd set xdg-open.
Elsewhere, in xdg's settings, you'd tell it what your preferences are
for handling PDF files. This stage of configuration, I don't remember
the process. Your desktop "preferred applications" configurator may
set them for you, or it might just set its own preferred applications.
If your mail program "opens" the file, it'll send it to the application
configured in your mail program. If you "save" a file, it just gets
directly saved to your drive.
The advantage of using xdg-open for application/octet-stream
attachments is that if you receive a PDF sent that way, xdg-open should
(could) use the right reader to view a PDF; if you get sent a JPEG as
application/octet-stream, xdg-open should use an image viewer to view
the JPEG. Likewise for any other file mis-sent as that generic binary
description, it'd analyse the file and open it appropriately.
The alternative is that people try setting a PDF reader as the
application for application/octet-stream attachments, then things foul
up when they receive something other that PDF sent that way. And they
will receive various things misidentified that way.
Ideally, you should never receive any of the common types of files
misidentifed as that generic unknown binary mimetype, they've been
known about for decades.
I tend to save attached files and open the saved file, I'm not fond of
directly opening attachments. I often find that doesn't work as
straight-forwardly as you might wish.
>
> The attachments are being saved to a sub-folder of /tmp where the
> sub-folder name looks like it may have been named to reflect the pid
> of Thunderbird.
I would expect any of your applications ought to be able to open any
file saved in your name. There could be SELinux implications.
Did it save the file with a .pdf suffix, too?
>> A wild thought: Is it a filename with blank spaces in it?
> The attachment that is mimetype application/binary-octet does have
> embedded blanks in the attachment name, the attachment that is
> mimetype application/pdf doesn't have embedded blanks in the
> attachment name.
That can foul things up. It's 2023, but some applications still have
grief dealing with filenames with spaces in it. And there are so many
people using computers who never learnt that it can be a problem.
> Interestingly, I registered Acrobat as the default application for
> mimetype application/pdf, so when I clicked on the application/pdf
> mimetype attachment the prompt asked me if I wanted to open it the
> default of Acrobat, but to check to location of the file I selected
> Okular instead.
> When I then opened the email that had the mimetype
> application/binary-octet attachment, when I clicked on the attachment
> the prompt asked me if I wanted to open the file in Okular even
> though it had Acrobat as the default.
"What" has Acrobat set as the default? Thunderbird's setting for
handling application/pdf or application/octet-stream? Your desktop's
settings?
Mimetyping works thus:
When someone attaches a file to be sent, their software *should*
*correctly* identify the type of file it is in the mimetype header (and
in 2023 all programs that weren't written by a fool ought to know what
a PDF file is).
When you receive such an email, your email program should obey the
mimetype header, and nothing else. If the headers says its a PDF file,
then it hands it off to a PDF reader, no matter what the file really
is. Likewise for JPEGs, if the header says its a JPEG it hands it off
to the JPEG reader, even if it's not a JPEG. Et cetera...
If an attachment is described as application/octet-stream, it becomes a
"not my problem" issue to the mail program. You're expected to deal
with it by saving it and sorting it out yourself, or some other aspect
of your operating system may handle it (e.g xdg-open). The file is
palmed off. Thunderbird isn't told what it is externally, and doesn't
then open the file using your PDF viewer configured in Thunderbird.
Thunderbird doesn't do anything with that file.
But because application/octet-stream is the unknown binary file
descriptor, and you may receive *any* type of file, many different
types of files, described that way. Some programs may not let you set
a default application for it, because doing so is highly likely to
cause problems. You're forced to save the file, and deal with it some
other way. You may be stuck with this problem.
The list of applications to open various types of files in your email
program will be based on the mimetype they're described as, not what
the files actually are. The real solution is whatever's *WRONGLY*
attaching the files needs to be fixed. That's out of your control, and
will probably never get fixed, even if you report it to the sender.
-----------------------------
The counter-example of ignoring the mimetype descriptors in an email,
and letting the system do what it wants was the cause of many exploits
in windows email programs: Some jerk would send a dangerous executable
file in the mail, and they'd send it deliberately misidentifed as a
MIDI file. The windows email program would vaguely look at the header,
decide that MIDI files were safe and palm it off to the OS to open the
file as it saw fit. The system would determine what the file was, by
itself, work out it was an executable, and execute it.
That stupid situation existed for many years, it may still do, and
Microsoft never did anything to fix up the behaviour in their email
client, because they knew better than everyone else (in their own mind,
not in reality).
Now, if they'd obeyed mime typing and sent the executable exploit file
to the MIDI player, it would (should) have rejected the file as
unplayable, and no harm would (should) have happened.
Users should have had, also, mimetype configuration options in their
email program so that actually correctly identified as executable
attachments would be disallowed.
The world's "dumbest operating system ever" never ceased to amaze me at
just how stupidly it was designed, in a plethora of ways, and how they
never/rarely learnt from their mistakes.
----------------------------------
Extrapolating that behaviour to my suggestion of letting an email
program palm off all attached files to xdg-open, I find that it refuses
to execute any files. Scripts are opened in a text editor, binaries
fail with an error message:
[tim@fluffy ~]$ xdg-open /usr/bin/ls
gio: file:///usr/bin/ls: No application is registered as handling this
file
But I still manually handle most attachments, especially any difficult
ones.
--
NB: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the list.
The following system info data is generated fresh for each post:
uname -rsvp
Linux 6.1.7-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Jan 18 18:37:43
UTC 2023 x86_64
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
