I think there has been a lot of confusion around this issue and proposed mitigations, I'll try and clear things up, as best I can. First step: you definitely want to get to version 10.7.1 AND apply patch p276. This ensures you have the latest base, bug fixes, and vulnerability mitigations. Next I'll make one (NOT approved, sanctioned, or otherwise encouraged by SYMC , just MY opinion) editorial statement: I think JavaScript is an industry sanctioned RCE, and a malware vector that just begs to be exploited. (I don't know about you guys, but I make it a general practice to NOT allow remote command execution to occur on machines that I control). Having gotten that off my chest, I'll show you how to create a policy that will leave JavaScript, embedded in PDFs, alone. If/when/how to use it is up to you, your concience, and your business needs.
First, the basic assumptions:
You have a policy, called "Delete Executable Files Violations" which contains the condition "If the attachment or body part is in the attachment list" and the attachment list in question is "Executable Files (default)". If you are using a different policy name, or attachment list name, then substitute that policy/attachment list in the following instructions.
1. Create a new attachment list named 'PDFs'
2. Add TruType 'Portable Document Format' to the list.
a. Click 'If the True file type'
b. Click the File class 'Word Processor Document'
c. Click 'Portable Document Format'
d. Click 'Add'
3. Save
4. Edit the policy "Delete Executable Files Violations"
5. Click 'Disable decomposition of files in the list'
6. Select the attachment list "PDFs" that you just created.
7. Save
Now, your "Delete Executable Files Violations" policy has a new virtual 'AND' condition: 'AND the attachment in question is NOT found within a PDF.' Note that it ONLY afffects the one policy; it does NOT affect any other policy, or AV detection, or Disarm processing. You have, effectively, given a "bye" to JavaScript ONLY when it is embedded in a PDF.
However, you don't want to stop here, because the above policy opens up a hole for other executables (besides JavaScript) to slip through if they are embedded inside of a PDF. To resolve this you need to create a second file list and a second policy.
CAVEAT/WARNING: this second policy may have performace implications, also it is entirely possible for both policies to fire on the same message, which may lead to some confusing looking entries it the Message Audit Log
With warning in hand, here are the steps to create the second policy:
1. Create a copy of the attachment list "Executable Files (default)" named "Executable Files (without .js)"
2. Delete 'Extension is js'
3. Save
4. Create a copy of the policy "Delete Executable Files Violations" called "Delete Executable Files Violations inside PDFs"
5. Uncheck 'Disable decomposition of files in the list'
6. Edit the condition 'If the attachment or body part is in the attachment list "Executable Files (default)"'
7. Change the attachment list to "Executable Files (without .js)"
8. Click 'Update Condition'
9. Add a new condition
10. Select 'Attachment or body part is in the attachment list'
11. Select the attachment list "PDFs"
12. Select the two 'attachment list' conditions
13. Click '(X & Y)'
14. Ensure that the correct Policy Groups are selected
15. Save
This new policy will detect any non Javascript executables attached inside PDFs.
Of course you want to test this locally against some test policy group and ensure that it meets your business needs before going live, but I don't have to say that, right?
You now have a schizophrenic system that allow JavaScript through, as long as its embedded in a PDF, otherwise it will block it (assuming you are still using the default policy). If you have any doubt about the implications of "schizophrenic computers", just watch/re-watch 2001 A Space Odyssey. (I'm sorry Dave, I can't do that...)
Good Luck guys! :)