0

I found this solution for copying to the clipboard: Excel 2013 64-bit VBA: Clipboard API doesn't work

I added it to my code and everything worked great. But when I attached it to an email to send it to my work computer, Gmail balked, stating that there was a virus detected. After I removed the code from the above link, Gmail had no qualms about going ahead and sending the message on.

I'm wondering if there something specific about this code, if Gmail just doesn't like API calls, or if there's some other reason Gmail detected a virus. Also, if there are any work-arounds in case one is certain that there are no viruses in the file.

rmbradburn
  • 308
  • 1
  • 12
  • Have you tried to send some standard VBA code, without the API call? E.g., try with some `Workbook_Open()` event, which throws a MsgBox(). – Vityata Nov 26 '19 at 15:51
  • Yes. I didn't spell that out very well above. It sent just fine after I removed the code that calls the API to do the copy-to-clipboard, but the rest of my code (userform and VBA for the associated buttons, etc) was still in there. – rmbradburn Nov 26 '19 at 16:05

1 Answers1

0

Frankly, I cannot provide specific details about what Gmail looks for because I don't know the details. But I've run into that problem enough (with Gmail and also with a corporate IT managed Exchange server) to get a feel for when I can expect it.

The file extension in the attachment name is the largest predictor. I don't even bother attaching anything with the extensions: BAT, BAS, VBS,, JS, JVS, or HTA because I cannot count on them showing up and I won't get a delivery failure notice. This also happens with macro enabled files, XLSM, DOCM, XLAM, DOTM, etc.

At least some portion of the contents of the attachment are scanned too. Or, at least, that is the nference I make when I change the extension to TXT and the file doesn't show up. I can't say specifically if they are scanning a file and putting context to words or if they are matching patterns that indicate the actual file type. The later seems more practical considering possible resource or legal constraints.

Compressed archives aren't a sure thing either. In this case, I feel nearly certain the table of contents is being scanned and not the full archive. This could add weight to a theory that the full contents of a file are not scanned but that doesn't make it a fact. Zip files have always been hard for antivirus software to handle and reading the file names seems like low hanging fruit; in other words, scanning the body and putting context to contents remains a logical possibility.

Changing the file extension before adding the file to a compressed archive is my standard "go to". I do not believe I've had a file intercepted this way but the increasing weaponization of Zip files, it may only be a matter of time before this this stops working.

ProfoundlyOblivious
  • 1,455
  • 1
  • 6
  • 12
  • Thanks for the thoughts and things to consider. In this case, I believe I sent it as an XLSM both times, with the only difference being that the second time, I removed those specific API calls. This would lend further support to your theory that they're scanning files for specific things. – rmbradburn Feb 08 '20 at 22:33