john wrote: > 1. block all email with attachments - a little too drastic for some as there > are legit > reasons for attachments. > block all email that is in any format that can hide executable code.
IMO this won't work. > 2. rename attachments so that they will not/cannot be executed/run by just > opening > them. MIME type sniffing implemented in file viewers? > 3. only allow email with attachments from a preauthorized list of senders. I > am not > sure that this would be effective as sender addresses are (i believe) > easily > spoofed. Spammers use people's address books and even reuse message found in the "Sent" folder. > 4. email with attachments are diverted to a recipient for examination. If > cleared > they could then be forwarded to the original addressee. At lot of work for > someone. The most promising solution but huge amount of work if done right. > 5. a variation on 2. sender has to asks the recipient for permission to send > attachment. Recipient then adds sender to list, recipient will be > automagically > removed from list after a period of time. I can't imagine how this should work. Some of my customers have security guidelines with which they try to enforce to use a out-of-band file sharing service. Most times this is pretty cumbersome and error-prone. A variant of 4. could be to put messages with attachments in a sandboxed mailbox and only provide hardened web access to the message where the user can approve the message. Well, depending on your user base 99% of them just hit [OK]. In a known emergence case you could disabling approving messages completely though. > I am not keen on any of these. I think we all agree that any of such strategies will open a can of worms and might even not be feasible at all. > Another idea is to attachments are diverted and held for a period. After > which they > would be automatically be sent on as "normal". If there is something going on > then > the automatic forwarding would be suspended. Also keep in mind that some people might digitally sign e-mails including attachments. So you have to keep message signature intact. Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
