Message ID | 1513908937-16034-1-git-send-email-jasowang@redhat.com |
---|---|
State | New |
Headers | show |
On 22 December 2017 at 02:15, Jason Wang <jasowang@redhat.com> wrote: > The following changes since commit 43ab9a5376c95c61ae898a222c4d04bdf60e239b: > > hw/i386/vmport: fix missing definitions with non-log trace backends (2017-12-21 22:52:28 +0000) > > are available in the git repository at: > > https://github.com/jasowang/qemu.git tags/net-pull-request > > for you to fetch changes up to 0065e915192cdf83c2700bb377e5323c2649476e: > > qemu-doc: Update the deprecation information of -tftp, -bootp, -redir and -smb (2017-12-22 10:06:05 +0800) > > ---------------------------------------------------------------- > > ---------------------------------------------------------------- Applied, thanks. PS: just noticed, but "Ed Swierk via Qemu-devel <qemu-devel@nongnu.org>" is a bit of an odd Author string to end up in git commit logs, so you and/or Ed might like to fix that up for any future patches. thanks -- PMM
On Jan 8, 2018 02:16, "Peter Maydell" <peter.maydell@linaro.org> wrote: On 22 December 2017 at 02:15, Jason Wang <jasowang@redhat.com> wrote: > The following changes since commit 43ab9a5376c95c61ae898a222c4d04 bdf60e239b: > > hw/i386/vmport: fix missing definitions with non-log trace backends (2017-12-21 22:52:28 +0000) > > are available in the git repository at: > > https://github.com/jasowang/qemu.git tags/net-pull-request > > for you to fetch changes up to 0065e915192cdf83c2700bb377e5323c2649476e: > > qemu-doc: Update the deprecation information of -tftp, -bootp, -redir and -smb (2017-12-22 10:06:05 +0800) > > ---------------------------------------------------------------- > > ---------------------------------------------------------------- Applied, thanks. PS: just noticed, but "Ed Swierk via Qemu-devel <qemu-devel@nongnu.org>" is a bit of an odd Author string to end up in git commit logs, so you and/or Ed might like to fix that up for any future patches. Thanks for pointing that out. I wonder if it's happening because I let git-send-email automatically fill in the From: line. Anyway if it's not too late to fix, the correct address is Ed Swierk < eswierk@skyportsystems.com> . thanks -- PMM
On 01/08/2018 07:30 AM, Ed Swierk via Qemu-devel wrote: > Applied, thanks. > > PS: just noticed, but "Ed Swierk via Qemu-devel <qemu-devel@nongnu.org>" > is a bit of an odd Author string to end up in git commit logs, so you > and/or Ed might like to fix that up for any future patches. > > > Thanks for pointing that out. I wonder if it's happening because I let > git-send-email automatically fill in the From: line. It's also a factor of how strict your ISP is about DMARC handling; the list automatically rewrites the 'From:' header to insert the 'via Qemu-devel' tag if it detects DMARC settings at your ISP that won't allow your email through as originally written. Sadly, mailman doesn't know to insert a manual 'From:' line in the body when it rewrites the original From: header; but if you know that DMARC settings are going to munge your original header, you can probably convince git to always insert an explicit From: line in the message body to override whatever munging the list does. > > Anyway if it's not too late to fix, the correct address is Ed Swierk < > eswierk@skyportsystems.com> . You can also submit a patch against .mailmap so that existing submissions with the suspect data will at least be credited to the correct address for the purposes of crawling through git history.
On 01/08/2018 09:10 AM, Eric Blake wrote: > On 01/08/2018 07:30 AM, Ed Swierk via Qemu-devel wrote: > >> Applied, thanks. >> >> PS: just noticed, but "Ed Swierk via Qemu-devel <qemu-devel@nongnu.org>" >> is a bit of an odd Author string to end up in git commit logs, so you >> and/or Ed might like to fix that up for any future patches. >> >> >> Thanks for pointing that out. I wonder if it's happening because I let >> git-send-email automatically fill in the From: line. > > It's also a factor of how strict your ISP is about DMARC handling; the > list automatically rewrites the 'From:' header to insert the 'via > Qemu-devel' tag if it detects DMARC settings at your ISP that won't > allow your email through as originally written. Sadly, mailman doesn't > know to insert a manual 'From:' line in the body when it rewrites the > original From: header; but if you know that DMARC settings are going to > munge your original header, you can probably convince git to always > insert an explicit From: line in the message body to override whatever > munging the list does. > Hmm - we probably ought to enhance checkpatch.pl to insist that patches attributed to qemu-devel@nongnu.org as the author should be flagged as invalid, since the list munging is a 1:M mapping rather than 1:1, and therefore not easily invertable.
On 01/08/2018 09:18 AM, Eric Blake wrote: > Hmm - we probably ought to enhance checkpatch.pl to insist that patches > attributed to qemu-devel@nongnu.org as the author should be flagged as > invalid, since the list munging is a 1:M mapping rather than 1:1, and > therefore not easily invertable. Stefan reminded me on IRC that checkpatch.pl doesn't process From: lines (it only sees patches, not mboxes) - but that patchew could be taught to make this sort of check.
On Mon, Jan 8, 2018 at 7:10 AM, Eric Blake <eblake@redhat.com> wrote: > > On 01/08/2018 07:30 AM, Ed Swierk via Qemu-devel wrote: > > > Applied, thanks. > > > > PS: just noticed, but "Ed Swierk via Qemu-devel <qemu-devel@nongnu.org>" > > is a bit of an odd Author string to end up in git commit logs, so you > > and/or Ed might like to fix that up for any future patches. > > > > > > Thanks for pointing that out. I wonder if it's happening because I let > > git-send-email automatically fill in the From: line. > > It's also a factor of how strict your ISP is about DMARC handling; the > list automatically rewrites the 'From:' header to insert the 'via > Qemu-devel' tag if it detects DMARC settings at your ISP that won't > allow your email through as originally written. Sadly, mailman doesn't > know to insert a manual 'From:' line in the body when it rewrites the > original From: header; but if you know that DMARC settings are going to > munge your original header, you can probably convince git to always > insert an explicit From: line in the message body to override whatever > munging the list does. I'm trying to figure out what I need to fix on my end. I went back and looked at the email headers. Here are the two that ended up with the wrong author: Return-Path: <eswierk@skyportsystems.com> Received: from eswierk-sc.localdomain (67-207-112-138.static.wiline.com. [67.207.112.138]) by smtp.gmail.com with ESMTPSA id d9sm20150979pfk.117.2017.11.14.15.23.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 14 Nov 2017 15:23:44 -0800 (PST) From: Ed Swierk <eswierk@skyportsystems.com> To: Jason Wang <jasowang@redhat.com>, "Daniel P . Berrange" <berrange@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com> Cc: qemu-devel@nongnu.org, Ed Swierk <eswierk@skyportsystems.com> Subject: [PATCH 1/2] e1000, e1000e: Move per-packet TX offload flags out of context state Date: Tue, 14 Nov 2017 15:23:33 -0800 Message-Id: <1510701814-52973-2-git-send-email-eswierk@skyportsystems.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1510701814-52973-1-git-send-email-eswierk@skyportsystems.com> References: <1510701814-52973-1-git-send-email-eswierk@skyportsystems.com> Return-Path: <eswierk@skyportsystems.com> Received: from eswierk-sc.localdomain (67-207-112-138.static.wiline.com. [67.207.112.138]) by smtp.gmail.com with ESMTPSA id d9sm20150979pfk.117.2017.11.14.15.23.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 14 Nov 2017 15:23:45 -0800 (PST) From: Ed Swierk <eswierk@skyportsystems.com> To: Jason Wang <jasowang@redhat.com>, "Daniel P . Berrange" <berrange@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com> Cc: qemu-devel@nongnu.org, Ed Swierk <eswierk@skyportsystems.com> Subject: [PATCH 2/2] e1000: Separate TSO and non-TSO contexts, fixing UDP TX corruption Date: Tue, 14 Nov 2017 15:23:34 -0800 Message-Id: <1510701814-52973-3-git-send-email-eswierk@skyportsystems.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1510701814-52973-1-git-send-email-eswierk@skyportsystems.com> References: <1510701814-52973-1-git-send-email-eswierk@skyportsystems.com> This one had the correct author: Return-Path: <eswierk@skyportsystems.com> Received: from eswierk-sc.localdomain (67-207-112-138.static.wiline.com. [67.207.112.138]) by smtp.gmail.com with ESMTPSA id s3sm4082810pfk.7.2017.11.16.06.06.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Nov 2017 06:06:37 -0800 (PST) From: Ed Swierk <eswierk@skyportsystems.com> To: Jason Wang <jasowang@redhat.com>, "Daniel P . Berrange" <berrange@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com>, Dmitry Fleytman <dmitry@daynix.com> Cc: qemu-devel@nongnu.org, Ed Swierk <eswierk@skyportsystems.com> Subject: [PATCH v3 REPOST] net: Transmit zero UDP checksum as 0xFFFF Date: Thu, 16 Nov 2017 06:06:06 -0800 Message-Id: <1510841166-40615-1-git-send-email-eswierk@skyportsystems.com> X-Mailer: git-send-email 1.9.1 Is there any way to tell exactly what mailman didn't like about the first two, causing it to change the author? --Ed
On 01/08/2018 09:54 AM, Ed Swierk wrote: >> It's also a factor of how strict your ISP is about DMARC handling; the >> list automatically rewrites the 'From:' header to insert the 'via >> Qemu-devel' tag if it detects DMARC settings at your ISP that won't >> allow your email through as originally written. Sadly, mailman doesn't >> know to insert a manual 'From:' line in the body when it rewrites the >> original From: header; but if you know that DMARC settings are going to >> munge your original header, you can probably convince git to always >> insert an explicit From: line in the message body to override whatever >> munging the list does. > > I'm trying to figure out what I need to fix on my end. I went back and > looked at the email headers. Here are the two that ended up with the > wrong author: https://dmarc.org/wiki/FAQ has some more information on DMARC. There's two aspects to it: one is that the domain in charge of the policy can choose default reactions to any mail claiming to be sent from that domain (valid, none, flag, reject); the other is that recipients can choose whether to honor DMARC settings (some recipients let all mail through, even if DMARC said to flag or reject it, others are stricter and drop mail that DMARC marked as reject). We had list readers complaining about not getting emails (tending to come from recipients that drop mails when DMARC says reject, and only mails from senders where DMARC was set to reject rather than to flag), so we enabled the mailman settings that rewrite the From: line based on a DMARC lookup of the sender's information. > > Return-Path: <eswierk@skyportsystems.com> > Received: from eswierk-sc.localdomain > (67-207-112-138.static.wiline.com. [67.207.112.138]) > by smtp.gmail.com with ESMTPSA id > d9sm20150979pfk.117.2017.11.14.15.23.43 > (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); > Tue, 14 Nov 2017 15:23:44 -0800 (PST) > From: Ed Swierk <eswierk@skyportsystems.com> Here, it looks like your local system picked gmail.com as its SMTP server, and since gmail does not have an IP address in the range that skyportsystems.com claims under its DMARC listings, your mail is rejected rather than flagged by recipients that honor DMARC, so mailman munged the header to let recipients get the mail anyway. > This one had the correct author: > > Return-Path: <eswierk@skyportsystems.com> > Received: from eswierk-sc.localdomain > (67-207-112-138.static.wiline.com. [67.207.112.138]) > by smtp.gmail.com with ESMTPSA id s3sm4082810pfk.7.2017.11.16.06.06.36 > (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); > Thu, 16 Nov 2017 06:06:37 -0800 (PST) > From: Ed Swierk <eswierk@skyportsystems.com> That shows the same IP address as the sending location and again shows a path through gmail.com, so I'm not sure why it was handled differently, unless skyportsystems.com was changing DMARC policies between the two messages, or if you really did send the two mails through different setups. The most annoying thing about DMARC is that most end users do NOT have control over their domain's choice of DMARC settings; but the rule of thumb is "if your domain has a strict DMARC policy, then mail sent claiming to be from that domain must go through the SMTP servers whitelisted by that domain", coupled with mailman's policy that "if a message was sent from a domain with a DMARC that rejects the mailing list IP, then rewrite the header to make the mail appear to come from the list instead". Meanwhile, as an example, I used to be able to spoof my redhat.com email address when sending from my home computer and connecting to my ISP as the SMTP sender; but about a year ago, Red Hat tightened their DMARC settings so that if I want to send a mail that purports to be from redhat.com, I now have to send it through Red Hat's SMTP server, rather than my personal one, or else I risk my message not reaching the end recipient. But Red Hat's DMARC policy merely flags rather than rejecting spoofed emails, and because it is not marked as reject, mailman does not munge the headers of mails I send to the list.