Beating a dead horse here, but again, assuming you aren't running antivirus and
you are just doing a basic attachment check, you should be looking for file.com
or file.zip containing file.com, but not a file.com.zip containing file.com in
the file name, with an xml inside... if your receiver is
As is standard settings in lot of AV mailscanners to not allow
attachments as example with a .com in it.
Therefore it is not a good idea that google is sending attachments DMARC
with these filename !google.com!domain.comgjdsadg6777.zip bacause of
the .com names in it these are rejected in lot
I'd disagree about content filtering completely. There are some file
extensions that are inherently dangerous in the Windows world and .COM
is one of them.
If your AV depends on the filenames in the attachment headers, you've
already lost. It needs to look at the attachment contents to see
On 2015-08-25 09:56, John Levine via dmarc-discuss wrote:
As is standard settings in lot of AV mailscanners to not allow
attachments as example with a .com in it.
Therefore it is not a good idea that google is sending attachments DMARC
with these filename !google.com!domain.comgjdsadg6777.zip
indeed, but seems the filter is looking for .com anywhere in the filename
string, rather than at the end... I say bad design.
in DMARC filenames end up with .xml, .zip or .gzip
On Tue, Aug 25, 2015 at 11:05 AM, Dave Warren via dmarc-discuss
dmarc-discuss@dmarc.org wrote:
On 2015-08-25 09:56,
How about you don't just execute attachments sent to a reporting address?
It's all meant to be processed programmatically based on its contents, not
clicked on by a human in Windows 98. In 2015, virus filtering this feed is
about as nonsensical as spam content filtering the abuse mailbox. Even if
Note that the failure reports contains even more information that will
trigger the filters, therefore both addresses (rue and ruf) should be set
up to allow such reports to come in. Fix your filters would be my answer.
On Sun, Aug 23, 2015 at 11:35 AM, jotest via dmarc-discuss
