Re: [RFC PATCH v2 0/9] vhost lock annotations

[David Marchand <david.marchand@redhat.com>]

On Wed, Mar 30, 2022 at 4:37 PM Ali Alnubani <alialnu@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@.
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