/openAction can be considered malicious

[ErikKrause]

Since /OpenAction can be used to execute malware* (and hence documents containing it might be blocked by virus scanners) it would be nice to have an option to disable it. Since all is written in the _putcatalog() function it would be easiest to add elseif ($this->ZoomMode == 'none') {} there and or $zoom == 'none' to SetDisplayMode function. And of course add to the documentation...

*See https://www.google.de/search?q=PDF+%2FOpenAction+malware

[guilherme-miranda]

I have this problem. Customers email is blocking the PDF file.

[guilherme-miranda]

Just to complement, I did some testing, and the files generated by version 6.0 do not have this problem.
As we updated the PHP version of the server, we also upgraded MPDF and from that started the problem.

[finwe]

Can you compare and/or provide those files? Maybe share a HTML/PHP code used to generate files causing this behaviour? What software exactly is blocking the files?

[guilherme-miranda]

E-mail from customers is refusing the message, and sending to SPAM.
I'm using the https://github.com/jesparza/peepdf tool to analyze PDF files.
Follows image with file analysis.
https://imgur.com/N20Ss7n

[finwe]

Can you compare and/or provide those files (6.0 vs 7+)? Maybe share a HTML/PHP code used to generate files causing this behaviour? What software exactly is marking the files as spam? (what e-mail provider)? Can you get headers of the delivered mail to see spam marking headers?

[ErikKrause]

You don't need to do anything special. _putcatalog will write /OpenAction into the PDF in any case. Even if there is no ZoomMode set

    } else {
      $this->_out('/OpenAction [3 0 R /XYZ null null null]');
    }

will cut in.

Sorry, I don't know which software caused the rejection of the PDFs. We got complaints from customers that the attachment was stripped from a mail, which was enough for me to search for the culprit. VirusTotal gave me a warning about /OpenAction which made me investigate a bit more (see google link above). So I changed Mpdf.php as indicated above. PDF document still works as intended, no complaints since, problem solved.

You can try to upload f.e. https://github.com/mpdf/mpdf-examples/blob/development/pdf/sample_basic.pdf to virustotal. The file is scanned clean, only under Details -> PDF Info you get the warning.

[guilherme-miranda]

Follows a client's email image (GMAIL) for example.
https://imgur.com/llSiBxa

The message says:

"Be careful with this message. It contains a suspicious link used to steal personal information.
If you do not trust the sender, do not click on the links or send personal information. "

HTML code to generate PDF:

```
$mpdf = new \Mpdf\Mpdf(['orientation' => $orientation, 'tempDir' => FCPATH . 'temp']);

$mpdf->simpleTables = true;
$mpdf->packTableData = true;
$mpdf->AddPage('','',$startpage, '1','off');
$mpdf->WriteHTML($html);

if ($stream){
    $mpdf->Output($filename . '.pdf', 'I');
}else{
    $mpdf->Output('./temp/' . $filename . '.pdf', 'F');

    return './temp/' . $filename . '.pdf';
}

[squareconcepts]

We also have this problem. When I remove the pdf that is generated by Mpdf, it reaches the inbox. When I add the pdf, it doesn't reach the inbox.

The server log says the following:
This message was blocked because its content presents a potential\n552-5.7.0 security issue. Please visit\n552-5.7.0 https://support.google.com/mail/?p=BlockedMessage to review our\n552 5.7.0 message content and attachment content guidelines.

Does anyone have a solution for this problem?

[finwe]

In development branch, this can be mitigated with $mpdf->SetDisplayMode('none'); - so that OpenAction will not be written.

Will be released with 8.0.1.

With 9.0, the default can be changed so that no OpenAction is written by default.