[RFC PATCH v2 0/9] vhost lock annotations

David Marchand david.marchand at redhat.com
Tue Apr 5 09:11:48 CEST 2022


On Wed, Mar 30, 2022 at 4:37 PM Ali Alnubani <alialnu at nvidia.com> wrote:
>
> [..]
> > It looks like mimecast shot the first patch (which I sent in place of
> > Maxime, because this series should go through the main repo).
> >
> > Looking at the mail source, I see:
> >
> > X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation
> > Protection Definition;Similar Internal Domain=false;Similar Monitored
> > External Domain=false;Custom External Domain=false;Mimecast External
> > Domain=false;Newly Observed Domain=false;Internal User
> > Name=false;Custom Display Name List=false;Reply-to Address
> > Mismatch=false;Targeted Threat Dictionary=false;Mimecast Threat
> > Dictionary=false;Custom Threat Dictionary=false
> >
> > I don't know how to understand this...
> > But as a result, the series is missing this patch in patchwork.
>
> I believe it was ignored by Patchwork because of its content-type (application/octet-stream), which indicates that the message contains binary data instead of text:
> > Content-Transfer-Encoding: 8bit
> > Content-Type: application/octet-stream; x-default=true

Probably the consequence of some Mimecast mangling.

I noticed similar issues in my inbox for some Luca mails on stable@
and some mails from @Intel people on dev@ and even on netdev at .
In all cases where From: contains a name != sender, my inbox got the
same "content stripped and attached" symptom.
On the other hand, those mails end up fine in public mail archives.

Looking at headers of publicly archived mails and comparing with what
I got, there is an additional trace of Mimecast between dpdk.org
server and my inbox.

I opened a IT ticket internally.
I hope it will get fixed quickly.


-- 
David Marchand



More information about the dev mailing list