You'll need to tell your anti-virus software not to scan messages.

Have you followed the way to that setting?

It clearly reads "Allow an anti virus program to put messages under quarantine." It's a TB type of thing, so it has to be somewhere inherent (hidden) in TB.

I'm also not aware of any software that might be able to toggle settings on or off within TB...

It's not really a preference to actively forbid or prevent scanning. Rather, it's a setting to facilitate scanning by placing messages into a separate file so an anti-virus scanner can examine them without necessarily messing up Thunderbird's own mail store.

Whether or not an anti virus software attempts to scan is dependent on the settings in the anti-virus software itself. Thunderbird cannot dictate the behaviour of external programs.

Thank you for your explanation. I was pretty much aware of the way how Thunderbird handles anti-virus software for incoming mail (separate file).

Let's get back to my origin question, just to be clear on what I'm asking.

Today I've installed the english language pack and I kindly ask you to follow these steps: Edit -> Preferences -> Security -> Anti-Virus -> "Allow anti-virus clients to quarantine individual incoming messages"

You can toggle this on and off.

Somewhere inherent in TB this setting must get saved. Do you agree? And because it's not listed in the "unhidden" preferences, I assume that this setting is one of the hidden ones. Do you agree again?

And this is what I need: The name of that hidden preference.

The preference you are looking for is:

mailnews.downloadToTempFile

where value = true means it is selected

Thanks alot, that's it!

Well, I searched for something like "virus", "malware", "quarantine" in the preferences.

Btw: Whatever you set it to (true, false) mailnews.downloadToTempFile keeps the status user defined. Also, it keeps displayed in bold in both cases.

Thanks again. Really appreciate that.

When we say "hidden" we generally mean that the setting can only be found (or accessed) in the Config Editor or prefs.js.

If it has a GUI control, such as a checkbox, as this one does, then it's not considered to be hidden.

I don't understand why you think setting the preference directly is any different from or more secure than ticking or unticking the GUI checkbox.

In general, any setting at its default value doesn't need to appear in prefs.js or Config Editor. So a setting can exist and be invisible until you change it from the default value. Using the "reset" option returns it to the default value and removes it from sight.

In my test, the pref appeared in the Config Editor after ticking the checkbox in the GUI - but you have to close and re-open Thunderbird to see this change. So long as you have caused this value to appear it will remain visible in Config Editor, in bold, because you, the user, has changed it. If you use the "reset" option, it will return to the default "false" status and it will be hidden in Config Editor/prefs.js again.

Tip: make a copy of prefs.js. Open Thunderbird, change a setting and close Thunderbird. Compare the revised prefs.js with the old copy.

IIRC, Notepad++ can compare files. Diffmerge is a useful tool, and you almost certainly have a file comparison tool in your command prompt.

http://www.howtogeek.com/206123/how-to-use-fc-file-compare-from-the-windows-command-prompt/?PageSpeed=noscript

Thanks for your explanation what you consider as a hidden pref and what makes it visible, if it's not shown in about:config.

The reason for setting the prefs directly is simple - there are a bunch of prefs you can't simply access in the online dialogs (=GUI boxes).

Let's name a few: - "browser.cache.*" - "canvas.*" - "dom.*" - "mailnews.* (partly) - "media.*" (IMHO: TB is a mail client, not a multi media player) - "privacy.*" - "security.*" - "webgl.*"

I'm privacy and security conscious, so I kind of "hardened" TB this way.

I also distribute that user.js in my classes for those who are interested in increased privacy.

btw: It is way easier to copy a file with your basic and extended settings than to click through dozens of boxes on a fresh installation / existing installation.

And well, unfortunately I can't use Notepad++ anymore, because I dropped Windows some time ago for a nice Linux distribution.

But Meld should do the same job: http://meldmerge.org/

My 'prefs.js' file only shows preferences I have selected or changed from the default. It does not show any unchanged default settings. So this would not be the place to look for them, which probably explains why you could not locate what you were looking for.

The Config Editor - about:config will show default entries that I have and have not specified any changes. Hence why I could easily locate that information for you. re :there are a bunch of prefs you can't simply access in the online dialogs (=GUI boxes). followed by a list. Please note that all of those preferences you listed are visible via my Config Editor which if modified will update the 'prefs.js' file.

So if looking for certain eg: webgl preferences then you are not likely to find them in the prefs.js file if you have not made the changes via Config Editor. If you change them via Config Editor then they will show up in prefs.js.

It is also possible to add new entries via Config Editor.

There is no advantage in changing anything in a 'user.js' file, if it can already be set safely via Config Editor method to update the 'prefs.js' file.

For example: the preference you asked about: mailnews.downloadToTempFile This is in Config Editor - about:config window and can only be either false or true, so nothing that would require it to be in a 'user.js' file. If you alter it from the default it will have a Status as 'User Set' in Config Editor and then it would appear in the 'prefs.js' file. There is nothing gained putting this in a 'user.js' file.

However, the 'user.js' file is really useful if changing the default setting but do not want to potentially mess up the 'prefs.js' file as some changes are not possible via Config Editor ... such as modifying this next preference to include a line break. Line breaks cannot be added via Config Editor method. eg: user_pref("mailnews.reply_header_ondateauthorwrote")

So, there are occasions when using a 'user.js' file is better than altering the 'prefs.js' especially when it cannot be altered via Config Editor.

re:btw: It is way easier to copy a file with your basic and extended settings than to click through dozens of boxes on a fresh installation / existing installation.

It's even easier to copy paste the entire profile folder name contents, hence copying all preferences, mail accounts, address books etc anyway.

At the end of the day it is your choice, but if you are only making the kind of changes that could already be done via Config Editor then there is little point spending the time and effort for no gains.

Well, if you have a set of standardized settings that you want to apply, then I can see that pasting in a standard prefs file is attractive. But safe only so long as that means using a proven prefs file and not ad-hoc editing. And just how often would the average user need to tweak a new installation of Thunderbird? Invariably, I use and build on a pre-existing profile.

I would never advise hand editing prefs files as a routine procedure. Any small error in syntax is enough to break Thunderbird completely. This is super user territory.

But you could have found the "hidden" setting for yourself by diff'ing the prefs file for changes. If you think that tweaking the files directly is OK then I'd sincerely hope that you'd also be sufficiently competent to use a diff facility.

Your comments about bold entries in the Config Editor led me to think that you weren't perhaps sufficiently familiar with the settings to be attempting hand editing. Sometimes a little knowledge is dangerous. Or, "If it ain't broke, I haven't fixed it enough." ;-)

BTW, I still think the logic implied in your original question is faulty. The setting facilitates the scanning of messages by decoupling them from the message store, and thereby limiting the damage that may be inflicted on your message store by a rampant anti-virus system.

The setting we have been looking for neither "enables" nor "prohibits" anti-virus scanning. If you promote this setting as preventing AV scanning then you will be misleading your classes.

Agree with Zenos. AV software has to be instructed not to scan Thunderbird folders on startup and also not scan incoming and outgoing emails if you do not want this to occur.

Perhaps I was not clear enough what I wanted to accomplish. English is not my native language.

I've found what I've been looking for, tested it exhaustive with a fake virus, a crash-and-burn-profile and everything's been working as I wanted it to work.

So much for "having fixed it til it's broken" and "competence".

Gentlemen, thank you.