BANNED contents from you (application/octet-stream, .exe, .exe-ms, data.scr)

[Iago Rubio]

This email was not sent from any of me email servers.

The email address was spoofed.

Please check my DNS/SPF records.

The address 106.76.101.240 hav3 nothing to do with this domain.

Please don't bounce spoofed emails.

Thank you.

En 17 abr. 2021 14:13, en 14:13, "Content-filter at natalya.videolan.org" <postmaster@natalya.videolan.org> escribió:
>BANNED CONTENTS ALERT
>
>Our content checker found
>    banned name: application/octet-stream,.exe,.exe-ms,data.scr
>
>in email presumably from you <newlib@sourceware.org>
>to the following recipient:
>-> jpeg@videolan.org
>
>Our internal reference code for your message is 20177-17/RFHASaHAYZ-D
>
>First upstream SMTP client IP address: [106.76.101.240] 
>According to a 'Received:' trace, the message apparently originated at:
>  [106.76.101.240], videolan.org unknown [106.76.101.240]
>
>Return-Path: <newlib@sourceware.org>
>From: newlib@sourceware.org
>Subject: Re: Protected Mail Request
>
>Delivery of the email was stopped!
>
>The message has been blocked because it contains a component
>(as a MIME part or nested within) with declared name
>or MIME type or contents type violating our access policy.
>
>To transfer contents that may be considered risky or unwanted
>by site policies, or simply too large for mailing, please consider
>publishing your content on the web, and only sending an URL of the
>document to the recipient.
>
>Depending on the recipient and sender site policies, with a little
>effort it might still be possible to send any contents (including
>viruses) using one of the following methods:
>
>- encrypted using pgp, gpg or other encryption methods;
>
>- wrapped in a password-protected or scrambled container or archive
>  (e.g.: zip -e, arj -g, arc g, rar -p, or other methods)
>
>Note that if the contents is not intended to be secret, the
>encryption key or password may be included in the same message
>for recipient's convenience.
>
>We are sorry for inconvenience if the contents was not malicious.
>
>The purpose of these restrictions is to cut the most common propagation
>methods used by viruses and other malware. These often exploit
>automatic
>mechanisms and security holes in more popular mail readers (Microsoft
>mail readers and browsers are a common target). By requiring an
>explicit
>and decisive action from the recipient to decode mail, the danger of
>automatic malware propagation is largely reduced.