| Message ID | 20220428120837.3737765-1-yukuai3@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | support concurrent sync io for bfq on a specail occasion | expand |
Hi, Paolo Can you take a look at this patchset? It has been quite a long time since we spotted this problem... Thanks, Kuai 在 2022/04/28 20:08, Yu Kuai 写道: > Changes in v5: > - rename bfq_add_busy_queues() to bfq_inc_busy_queues() in patch 1 > - fix wrong definition in patch 1 > - fix spelling mistake in patch 2: leaset -> least > - update comments in patch 3 > - add reviewed-by tag in patch 2,3 > > Changes in v4: > - split bfq_update_busy_queues() to bfq_add/dec_busy_queues(), > suggested by Jan Kara. > - remove unused 'in_groups_with_pending_reqs', > > Changes in v3: > - remove the cleanup patch that is irrelevant now(I'll post it > separately). > - instead of hacking wr queues and using weights tree insertion/removal, > using bfq_add/del_bfqq_busy() to count the number of groups > (suggested by Jan Kara). > > Changes in v2: > - Use a different approch to count root group, which is much simple. > > Currently, bfq can't handle sync io concurrently as long as they > are not issued from root group. This is because > 'bfqd->num_groups_with_pending_reqs > 0' is always true in > bfq_asymmetric_scenario(). > > The way that bfqg is counted into 'num_groups_with_pending_reqs': > > Before this patchset: > 1) root group will never be counted. > 2) Count if bfqg or it's child bfqgs have pending requests. > 3) Don't count if bfqg and it's child bfqgs complete all the requests. > > After this patchset: > 1) root group is counted. > 2) Count if bfqg have at least one bfqq that is marked busy. > 3) Don't count if bfqg doesn't have any busy bfqqs. > > The main reason to use busy state of bfqq instead of 'pending requests' > is that bfqq can stay busy after dispatching the last request if idling > is needed for service guarantees. > > With the above changes, concurrent sync io can be supported if only > one group is activated. > > fio test script(startdelay is used to avoid queue merging): > [global] > filename=/dev/nvme0n1 > allow_mounted_write=0 > ioengine=psync > direct=1 > ioscheduler=bfq > offset_increment=10g > group_reporting > rw=randwrite > bs=4k > > [test1] > numjobs=1 > > [test2] > startdelay=1 > numjobs=1 > > [test3] > startdelay=2 > numjobs=1 > > [test4] > startdelay=3 > numjobs=1 > > [test5] > startdelay=4 > numjobs=1 > > [test6] > startdelay=5 > numjobs=1 > > [test7] > startdelay=6 > numjobs=1 > > [test8] > startdelay=7 > numjobs=1 > > test result: > running fio on root cgroup > v5.18-rc1: 550 Mib/s > v5.18-rc1-patched: 550 Mib/s > > running fio on non-root cgroup > v5.18-rc1: 349 Mib/s > v5.18-rc1-patched: 550 Mib/s > > Note that I also test null_blk with "irqmode=2 > completion_nsec=100000000(100ms) hw_queue_depth=1", and tests show > that service guarantees are still preserved. > > Previous versions: > RFC: https://lore.kernel.org/all/20211127101132.486806-1-yukuai3@huawei.com/ > v1: https://lore.kernel.org/all/20220305091205.4188398-1-yukuai3@huawei.com/ > v2: https://lore.kernel.org/all/20220416093753.3054696-1-yukuai3@huawei.com/ > v3: https://lore.kernel.org/all/20220427124722.48465-1-yukuai3@huawei.com/ > v4: https://lore.kernel.org/all/20220428111907.3635820-1-yukuai3@huawei.com/ > > Yu Kuai (3): > block, bfq: record how many queues are busy in bfq_group > block, bfq: refactor the counting of 'num_groups_with_pending_reqs' > block, bfq: do not idle if only one group is activated > > block/bfq-cgroup.c | 1 + > block/bfq-iosched.c | 48 +++----------------------------------- > block/bfq-iosched.h | 57 +++++++-------------------------------------- > block/bfq-wf2q.c | 35 +++++++++++++++++----------- > 4 files changed, 35 insertions(+), 106 deletions(-) >
在 2022/05/05 9:00, yukuai (C) 写道: > Hi, Paolo > > Can you take a look at this patchset? It has been quite a long time > since we spotted this problem... > friendly ping ... > Thanks, > Kuai > > 在 2022/04/28 20:08, Yu Kuai 写道: >> Changes in v5: >> - rename bfq_add_busy_queues() to bfq_inc_busy_queues() in patch 1 >> - fix wrong definition in patch 1 >> - fix spelling mistake in patch 2: leaset -> least >> - update comments in patch 3 >> - add reviewed-by tag in patch 2,3 >> >> Changes in v4: >> - split bfq_update_busy_queues() to bfq_add/dec_busy_queues(), >> suggested by Jan Kara. >> - remove unused 'in_groups_with_pending_reqs', >> >> Changes in v3: >> - remove the cleanup patch that is irrelevant now(I'll post it >> separately). >> - instead of hacking wr queues and using weights tree >> insertion/removal, >> using bfq_add/del_bfqq_busy() to count the number of groups >> (suggested by Jan Kara). >> >> Changes in v2: >> - Use a different approch to count root group, which is much simple. >> >> Currently, bfq can't handle sync io concurrently as long as they >> are not issued from root group. This is because >> 'bfqd->num_groups_with_pending_reqs > 0' is always true in >> bfq_asymmetric_scenario(). >> >> The way that bfqg is counted into 'num_groups_with_pending_reqs': >> >> Before this patchset: >> 1) root group will never be counted. >> 2) Count if bfqg or it's child bfqgs have pending requests. >> 3) Don't count if bfqg and it's child bfqgs complete all the requests. >> >> After this patchset: >> 1) root group is counted. >> 2) Count if bfqg have at least one bfqq that is marked busy. >> 3) Don't count if bfqg doesn't have any busy bfqqs. >> >> The main reason to use busy state of bfqq instead of 'pending requests' >> is that bfqq can stay busy after dispatching the last request if idling >> is needed for service guarantees. >> >> With the above changes, concurrent sync io can be supported if only >> one group is activated. >> >> fio test script(startdelay is used to avoid queue merging): >> [global] >> filename=/dev/nvme0n1 >> allow_mounted_write=0 >> ioengine=psync >> direct=1 >> ioscheduler=bfq >> offset_increment=10g >> group_reporting >> rw=randwrite >> bs=4k >> >> [test1] >> numjobs=1 >> >> [test2] >> startdelay=1 >> numjobs=1 >> >> [test3] >> startdelay=2 >> numjobs=1 >> >> [test4] >> startdelay=3 >> numjobs=1 >> >> [test5] >> startdelay=4 >> numjobs=1 >> >> [test6] >> startdelay=5 >> numjobs=1 >> >> [test7] >> startdelay=6 >> numjobs=1 >> >> [test8] >> startdelay=7 >> numjobs=1 >> >> test result: >> running fio on root cgroup >> v5.18-rc1: 550 Mib/s >> v5.18-rc1-patched: 550 Mib/s >> >> running fio on non-root cgroup >> v5.18-rc1: 349 Mib/s >> v5.18-rc1-patched: 550 Mib/s >> >> Note that I also test null_blk with "irqmode=2 >> completion_nsec=100000000(100ms) hw_queue_depth=1", and tests show >> that service guarantees are still preserved. >> >> Previous versions: >> RFC: >> https://lore.kernel.org/all/20211127101132.486806-1-yukuai3@huawei.com/ >> v1: >> https://lore.kernel.org/all/20220305091205.4188398-1-yukuai3@huawei.com/ >> v2: >> https://lore.kernel.org/all/20220416093753.3054696-1-yukuai3@huawei.com/ >> v3: >> https://lore.kernel.org/all/20220427124722.48465-1-yukuai3@huawei.com/ >> v4: >> https://lore.kernel.org/all/20220428111907.3635820-1-yukuai3@huawei.com/ >> >> Yu Kuai (3): >> block, bfq: record how many queues are busy in bfq_group >> block, bfq: refactor the counting of 'num_groups_with_pending_reqs' >> block, bfq: do not idle if only one group is activated >> >> block/bfq-cgroup.c | 1 + >> block/bfq-iosched.c | 48 +++----------------------------------- >> block/bfq-iosched.h | 57 +++++++-------------------------------------- >> block/bfq-wf2q.c | 35 +++++++++++++++++----------- >> 4 files changed, 35 insertions(+), 106 deletions(-) >>
在 2022/05/14 17:29, yukuai (C) 写道: > 在 2022/05/05 9:00, yukuai (C) 写道: >> Hi, Paolo >> >> Can you take a look at this patchset? It has been quite a long time >> since we spotted this problem... >> > > friendly ping ... friendly ping ... >> Thanks, >> Kuai >> >> 在 2022/04/28 20:08, Yu Kuai 写道: >>> Changes in v5: >>> - rename bfq_add_busy_queues() to bfq_inc_busy_queues() in patch 1 >>> - fix wrong definition in patch 1 >>> - fix spelling mistake in patch 2: leaset -> least >>> - update comments in patch 3 >>> - add reviewed-by tag in patch 2,3 >>> >>> Changes in v4: >>> - split bfq_update_busy_queues() to bfq_add/dec_busy_queues(), >>> suggested by Jan Kara. >>> - remove unused 'in_groups_with_pending_reqs', >>> >>> Changes in v3: >>> - remove the cleanup patch that is irrelevant now(I'll post it >>> separately). >>> - instead of hacking wr queues and using weights tree >>> insertion/removal, >>> using bfq_add/del_bfqq_busy() to count the number of groups >>> (suggested by Jan Kara). >>> >>> Changes in v2: >>> - Use a different approch to count root group, which is much simple. >>> >>> Currently, bfq can't handle sync io concurrently as long as they >>> are not issued from root group. This is because >>> 'bfqd->num_groups_with_pending_reqs > 0' is always true in >>> bfq_asymmetric_scenario(). >>> >>> The way that bfqg is counted into 'num_groups_with_pending_reqs': >>> >>> Before this patchset: >>> 1) root group will never be counted. >>> 2) Count if bfqg or it's child bfqgs have pending requests. >>> 3) Don't count if bfqg and it's child bfqgs complete all the requests. >>> >>> After this patchset: >>> 1) root group is counted. >>> 2) Count if bfqg have at least one bfqq that is marked busy. >>> 3) Don't count if bfqg doesn't have any busy bfqqs. >>> >>> The main reason to use busy state of bfqq instead of 'pending requests' >>> is that bfqq can stay busy after dispatching the last request if idling >>> is needed for service guarantees. >>> >>> With the above changes, concurrent sync io can be supported if only >>> one group is activated. >>> >>> fio test script(startdelay is used to avoid queue merging): >>> [global] >>> filename=/dev/nvme0n1 >>> allow_mounted_write=0 >>> ioengine=psync >>> direct=1 >>> ioscheduler=bfq >>> offset_increment=10g >>> group_reporting >>> rw=randwrite >>> bs=4k >>> >>> [test1] >>> numjobs=1 >>> >>> [test2] >>> startdelay=1 >>> numjobs=1 >>> >>> [test3] >>> startdelay=2 >>> numjobs=1 >>> >>> [test4] >>> startdelay=3 >>> numjobs=1 >>> >>> [test5] >>> startdelay=4 >>> numjobs=1 >>> >>> [test6] >>> startdelay=5 >>> numjobs=1 >>> >>> [test7] >>> startdelay=6 >>> numjobs=1 >>> >>> [test8] >>> startdelay=7 >>> numjobs=1 >>> >>> test result: >>> running fio on root cgroup >>> v5.18-rc1: 550 Mib/s >>> v5.18-rc1-patched: 550 Mib/s >>> >>> running fio on non-root cgroup >>> v5.18-rc1: 349 Mib/s >>> v5.18-rc1-patched: 550 Mib/s >>> >>> Note that I also test null_blk with "irqmode=2 >>> completion_nsec=100000000(100ms) hw_queue_depth=1", and tests show >>> that service guarantees are still preserved. >>> >>> Previous versions: >>> RFC: >>> https://lore.kernel.org/all/20211127101132.486806-1-yukuai3@huawei.com/ >>> v1: >>> https://lore.kernel.org/all/20220305091205.4188398-1-yukuai3@huawei.com/ >>> v2: >>> https://lore.kernel.org/all/20220416093753.3054696-1-yukuai3@huawei.com/ >>> v3: >>> https://lore.kernel.org/all/20220427124722.48465-1-yukuai3@huawei.com/ >>> v4: >>> https://lore.kernel.org/all/20220428111907.3635820-1-yukuai3@huawei.com/ >>> >>> Yu Kuai (3): >>> block, bfq: record how many queues are busy in bfq_group >>> block, bfq: refactor the counting of 'num_groups_with_pending_reqs' >>> block, bfq: do not idle if only one group is activated >>> >>> block/bfq-cgroup.c | 1 + >>> block/bfq-iosched.c | 48 +++----------------------------------- >>> block/bfq-iosched.h | 57 +++++++-------------------------------------- >>> block/bfq-wf2q.c | 35 +++++++++++++++++----------- >>> 4 files changed, 35 insertions(+), 106 deletions(-) >>>
On 5/21/22 1:22 AM, yukuai (C) wrote: > 在 2022/05/14 17:29, yukuai (C) 写道: >> 在 2022/05/05 9:00, yukuai (C) 写道: >>> Hi, Paolo >>> >>> Can you take a look at this patchset? It has been quite a long time >>> since we spotted this problem... >>> >> >> friendly ping ... > friendly ping ... I can't speak for Paolo, but I've mentioned before that the majority of your messages end up in my spam. That's still the case, in fact I just marked maybe 10 of them as not spam. You really need to get this issued sorted out, or you will continue to have patches ignore because folks may simply not see them.
在 2022/05/21 20:21, Jens Axboe 写道: > On 5/21/22 1:22 AM, yukuai (C) wrote: >> 在 2022/05/14 17:29, yukuai (C) 写道: >>> 在 2022/05/05 9:00, yukuai (C) 写道: >>>> Hi, Paolo >>>> >>>> Can you take a look at this patchset? It has been quite a long time >>>> since we spotted this problem... >>>> >>> >>> friendly ping ... >> friendly ping ... > > I can't speak for Paolo, but I've mentioned before that the majority > of your messages end up in my spam. That's still the case, in fact > I just marked maybe 10 of them as not spam. > > You really need to get this issued sorted out, or you will continue > to have patches ignore because folks may simply not see them. > Hi, Thanks for your notice. Is it just me or do you see someone else's messages from *huawei.com end up in spam? I tried to seek help from our IT support, however, they didn't find anything unusual...
On 5/22/22 7:10 PM, yukuai (C) wrote: > ? 2022/05/21 20:21, Jens Axboe ??: >> On 5/21/22 1:22 AM, yukuai (C) wrote: >>> ? 2022/05/14 17:29, yukuai (C) ??: >>>> ? 2022/05/05 9:00, yukuai (C) ??: >>>>> Hi, Paolo >>>>> >>>>> Can you take a look at this patchset? It has been quite a long time >>>>> since we spotted this problem... >>>>> >>>> >>>> friendly ping ... >>> friendly ping ... >> >> I can't speak for Paolo, but I've mentioned before that the majority >> of your messages end up in my spam. That's still the case, in fact >> I just marked maybe 10 of them as not spam. >> >> You really need to get this issued sorted out, or you will continue >> to have patches ignore because folks may simply not see them. >> > Hi, > > Thanks for your notice. > > Is it just me or do you see someone else's messages from *huawei.com > end up in spam? I tried to seek help from our IT support, however, they > didn't find anything unusual... Not sure, I think it's just you. It may be the name as well "yukuai (C)" probably makes gmail think it's not a real name? Or maybe it's the yukuai3 in the email? Pure speculation on my side.
在 2022/05/23 9:24, Jens Axboe 写道: > On 5/22/22 7:10 PM, yukuai (C) wrote: >> ? 2022/05/21 20:21, Jens Axboe ??: >>> On 5/21/22 1:22 AM, yukuai (C) wrote: >>>> ? 2022/05/14 17:29, yukuai (C) ??: >>>>> ? 2022/05/05 9:00, yukuai (C) ??: >>>>>> Hi, Paolo >>>>>> >>>>>> Can you take a look at this patchset? It has been quite a long time >>>>>> since we spotted this problem... >>>>>> >>>>> >>>>> friendly ping ... >>>> friendly ping ... >>> >>> I can't speak for Paolo, but I've mentioned before that the majority >>> of your messages end up in my spam. That's still the case, in fact >>> I just marked maybe 10 of them as not spam. >>> >>> You really need to get this issued sorted out, or you will continue >>> to have patches ignore because folks may simply not see them. >>> >> Hi, >> >> Thanks for your notice. >> >> Is it just me or do you see someone else's messages from *huawei.com >> end up in spam? I tried to seek help from our IT support, however, they >> didn't find anything unusual... > > Not sure, I think it's just you. It may be the name as well "yukuai (C)" Hi, Jens I just change this default name "yukuai (C)" to "Yu Kuai", can you please have a check if following emails still go to spam? https://lore.kernel.org/all/20220523082633.2324980-1-yukuai3@huawei.com/ > probably makes gmail think it's not a real name? Or maybe it's the > yukuai3 in the email? Pure speculation on my side. >
On Mon 23-05-22 09:10:38, yukuai (C) wrote: > 在 2022/05/21 20:21, Jens Axboe 写道: > > On 5/21/22 1:22 AM, yukuai (C) wrote: > > > 在 2022/05/14 17:29, yukuai (C) 写道: > > > > 在 2022/05/05 9:00, yukuai (C) 写道: > > > > > Hi, Paolo > > > > > > > > > > Can you take a look at this patchset? It has been quite a long time > > > > > since we spotted this problem... > > > > > > > > > > > > > friendly ping ... > > > friendly ping ... > > > > I can't speak for Paolo, but I've mentioned before that the majority > > of your messages end up in my spam. That's still the case, in fact > > I just marked maybe 10 of them as not spam. > > > > You really need to get this issued sorted out, or you will continue > > to have patches ignore because folks may simply not see them. > > > Hi, > > Thanks for your notice. > > Is it just me or do you see someone else's messages from *huawei.com > end up in spam? I tried to seek help from our IT support, however, they > didn't find anything unusual... So actually I have noticed that a lot of (valid) email from huawei.com (not just you) ends up in the spam mailbox. For me direct messages usually pass (likely matching SPF records for originating mail server save the email from going to spam) but messages going through mailing lists are flagged as spam because the emails are missing valid DKIM signature but huawei.com DMARC config says there should be DKIM signature (even direct messages are missing DKIM so this does not seem as a mailing list configuration issue). So this seems as some misconfiguration of the mails on huawei.com side (likely missing DKIM signing of outgoing email). Honza
On 5/23/22 2:18 AM, Yu Kuai wrote: > ? 2022/05/23 9:24, Jens Axboe ??: >> On 5/22/22 7:10 PM, yukuai (C) wrote: >>> ? 2022/05/21 20:21, Jens Axboe ??: >>>> On 5/21/22 1:22 AM, yukuai (C) wrote: >>>>> ? 2022/05/14 17:29, yukuai (C) ??: >>>>>> ? 2022/05/05 9:00, yukuai (C) ??: >>>>>>> Hi, Paolo >>>>>>> >>>>>>> Can you take a look at this patchset? It has been quite a long time >>>>>>> since we spotted this problem... >>>>>>> >>>>>> >>>>>> friendly ping ... >>>>> friendly ping ... >>>> >>>> I can't speak for Paolo, but I've mentioned before that the majority >>>> of your messages end up in my spam. That's still the case, in fact >>>> I just marked maybe 10 of them as not spam. >>>> >>>> You really need to get this issued sorted out, or you will continue >>>> to have patches ignore because folks may simply not see them. >>>> >>> Hi, >>> >>> Thanks for your notice. >>> >>> Is it just me or do you see someone else's messages from *huawei.com >>> end up in spam? I tried to seek help from our IT support, however, they >>> didn't find anything unusual... >> >> Not sure, I think it's just you. It may be the name as well "yukuai (C)" > Hi, Jens > > I just change this default name "yukuai (C)" to "Yu Kuai", can you > please have a check if following emails still go to spam? > > https://lore.kernel.org/all/20220523082633.2324980-1-yukuai3@huawei.com/ These did not go into spam, were delivered just fine.
On 5/23/22 2:59 AM, Jan Kara wrote: > On Mon 23-05-22 09:10:38, yukuai (C) wrote: >> ? 2022/05/21 20:21, Jens Axboe ??: >>> On 5/21/22 1:22 AM, yukuai (C) wrote: >>>> ? 2022/05/14 17:29, yukuai (C) ??: >>>>> ? 2022/05/05 9:00, yukuai (C) ??: >>>>>> Hi, Paolo >>>>>> >>>>>> Can you take a look at this patchset? It has been quite a long time >>>>>> since we spotted this problem... >>>>>> >>>>> >>>>> friendly ping ... >>>> friendly ping ... >>> >>> I can't speak for Paolo, but I've mentioned before that the majority >>> of your messages end up in my spam. That's still the case, in fact >>> I just marked maybe 10 of them as not spam. >>> >>> You really need to get this issued sorted out, or you will continue >>> to have patches ignore because folks may simply not see them. >>> >> Hi, >> >> Thanks for your notice. >> >> Is it just me or do you see someone else's messages from *huawei.com >> end up in spam? I tried to seek help from our IT support, however, they >> didn't find anything unusual... > > So actually I have noticed that a lot of (valid) email from huawei.com (not > just you) ends up in the spam mailbox. For me direct messages usually pass > (likely matching SPF records for originating mail server save the email > from going to spam) but messages going through mailing lists are flagged as > spam because the emails are missing valid DKIM signature but huawei.com > DMARC config says there should be DKIM signature (even direct messages are > missing DKIM so this does not seem as a mailing list configuration issue). > So this seems as some misconfiguration of the mails on huawei.com side > (likely missing DKIM signing of outgoing email). SPF/DKIM was indeed a problem earlier for yukaui patches, but I don't see that anymore. Maybe it's still an issue for some emails, from them or Huawei in general?
在 2022/05/23 20:36, Jens Axboe 写道: > On 5/23/22 2:18 AM, Yu Kuai wrote: >> ? 2022/05/23 9:24, Jens Axboe ??: >>> On 5/22/22 7:10 PM, yukuai (C) wrote: >>>> ? 2022/05/21 20:21, Jens Axboe ??: >>>>> On 5/21/22 1:22 AM, yukuai (C) wrote: >>>>>> ? 2022/05/14 17:29, yukuai (C) ??: >>>>>>> ? 2022/05/05 9:00, yukuai (C) ??: >>>>>>>> Hi, Paolo >>>>>>>> >>>>>>>> Can you take a look at this patchset? It has been quite a long time >>>>>>>> since we spotted this problem... >>>>>>>> >>>>>>> >>>>>>> friendly ping ... >>>>>> friendly ping ... >>>>> >>>>> I can't speak for Paolo, but I've mentioned before that the majority >>>>> of your messages end up in my spam. That's still the case, in fact >>>>> I just marked maybe 10 of them as not spam. >>>>> >>>>> You really need to get this issued sorted out, or you will continue >>>>> to have patches ignore because folks may simply not see them. >>>>> >>>> Hi, >>>> >>>> Thanks for your notice. >>>> >>>> Is it just me or do you see someone else's messages from *huawei.com >>>> end up in spam? I tried to seek help from our IT support, however, they >>>> didn't find anything unusual... >>> >>> Not sure, I think it's just you. It may be the name as well "yukuai (C)" >> Hi, Jens >> >> I just change this default name "yukuai (C)" to "Yu Kuai", can you >> please have a check if following emails still go to spam? >> >> https://lore.kernel.org/all/20220523082633.2324980-1-yukuai3@huawei.com/ > > These did not go into spam, were delivered just fine. > Cheers for solving this, I'll resend this patchset just in case they are in spam for Paolo...
On 5/23/22 6:58 AM, Yu Kuai wrote: > ? 2022/05/23 20:36, Jens Axboe ??: >> On 5/23/22 2:18 AM, Yu Kuai wrote: >>> ? 2022/05/23 9:24, Jens Axboe ??: >>>> On 5/22/22 7:10 PM, yukuai (C) wrote: >>>>> ? 2022/05/21 20:21, Jens Axboe ??: >>>>>> On 5/21/22 1:22 AM, yukuai (C) wrote: >>>>>>> ? 2022/05/14 17:29, yukuai (C) ??: >>>>>>>> ? 2022/05/05 9:00, yukuai (C) ??: >>>>>>>>> Hi, Paolo >>>>>>>>> >>>>>>>>> Can you take a look at this patchset? It has been quite a long time >>>>>>>>> since we spotted this problem... >>>>>>>>> >>>>>>>> >>>>>>>> friendly ping ... >>>>>>> friendly ping ... >>>>>> >>>>>> I can't speak for Paolo, but I've mentioned before that the majority >>>>>> of your messages end up in my spam. That's still the case, in fact >>>>>> I just marked maybe 10 of them as not spam. >>>>>> >>>>>> You really need to get this issued sorted out, or you will continue >>>>>> to have patches ignore because folks may simply not see them. >>>>>> >>>>> Hi, >>>>> >>>>> Thanks for your notice. >>>>> >>>>> Is it just me or do you see someone else's messages from *huawei.com >>>>> end up in spam? I tried to seek help from our IT support, however, they >>>>> didn't find anything unusual... >>>> >>>> Not sure, I think it's just you. It may be the name as well "yukuai (C)" >>> Hi, Jens >>> >>> I just change this default name "yukuai (C)" to "Yu Kuai", can you >>> please have a check if following emails still go to spam? >>> >>> https://lore.kernel.org/all/20220523082633.2324980-1-yukuai3@huawei.com/ >> >> These did not go into spam, were delivered just fine. >> > Cheers for solving this, I'll resend this patchset just in case they are > in spam for Paolo... Let's hope it's solved, you never know with gmail... But that series did go through fine as well, fwiw.
On Mon 23-05-22 06:36:58, Jens Axboe wrote: > On 5/23/22 2:59 AM, Jan Kara wrote: > > On Mon 23-05-22 09:10:38, yukuai (C) wrote: > >> ? 2022/05/21 20:21, Jens Axboe ??: > >>> On 5/21/22 1:22 AM, yukuai (C) wrote: > >>>> ? 2022/05/14 17:29, yukuai (C) ??: > >>>>> ? 2022/05/05 9:00, yukuai (C) ??: > >>>>>> Hi, Paolo > >>>>>> > >>>>>> Can you take a look at this patchset? It has been quite a long time > >>>>>> since we spotted this problem... > >>>>>> > >>>>> > >>>>> friendly ping ... > >>>> friendly ping ... > >>> > >>> I can't speak for Paolo, but I've mentioned before that the majority > >>> of your messages end up in my spam. That's still the case, in fact > >>> I just marked maybe 10 of them as not spam. > >>> > >>> You really need to get this issued sorted out, or you will continue > >>> to have patches ignore because folks may simply not see them. > >>> > >> Hi, > >> > >> Thanks for your notice. > >> > >> Is it just me or do you see someone else's messages from *huawei.com > >> end up in spam? I tried to seek help from our IT support, however, they > >> didn't find anything unusual... > > > > So actually I have noticed that a lot of (valid) email from huawei.com (not > > just you) ends up in the spam mailbox. For me direct messages usually pass > > (likely matching SPF records for originating mail server save the email > > from going to spam) but messages going through mailing lists are flagged as > > spam because the emails are missing valid DKIM signature but huawei.com > > DMARC config says there should be DKIM signature (even direct messages are > > missing DKIM so this does not seem as a mailing list configuration issue). > > So this seems as some misconfiguration of the mails on huawei.com side > > (likely missing DKIM signing of outgoing email). > > SPF/DKIM was indeed a problem earlier for yukaui patches, but I don't > see that anymore. Maybe it's still an issue for some emails, from them > or Huawei in general? Hum, for me all emails from Huawei I've received even today fail the DKIM check. After some more digging there is interesting inconsistency in DMARC configuration for huawei.com domain. There is DMARC record for huawei.com like: huawei.com. 600 IN TXT "v=DMARC1;p=none;rua=mailto:dmarc@edm.huawei.com" which means no DKIM is required but _dmarc.huawei.com has: _dmarc.huawei.com. 600 IN TXT "v=DMARC1;p=quarantine;ruf=mailto:dmarc@huawei.com;rua=mailto:dmarc@huawei.com" which says that DKIM is required. I guess this inconsistency may be the reason why there are problems with DKIM validation for senders from huawei.com. Yu Kuai, can you perhaps take this to your IT support to fix this? Either make sure huawei.com emails get properly signed with DKIM or remove the 'quarantine' record from _dmarc.huawei.com. Thanks! Honza
在 2022/05/23 23:25, Jan Kara 写道: > On Mon 23-05-22 06:36:58, Jens Axboe wrote: >> On 5/23/22 2:59 AM, Jan Kara wrote: >>> On Mon 23-05-22 09:10:38, yukuai (C) wrote: >>>> ? 2022/05/21 20:21, Jens Axboe ??: >>>>> On 5/21/22 1:22 AM, yukuai (C) wrote: >>>>>> ? 2022/05/14 17:29, yukuai (C) ??: >>>>>>> ? 2022/05/05 9:00, yukuai (C) ??: >>>>>>>> Hi, Paolo >>>>>>>> >>>>>>>> Can you take a look at this patchset? It has been quite a long time >>>>>>>> since we spotted this problem... >>>>>>>> >>>>>>> >>>>>>> friendly ping ... >>>>>> friendly ping ... >>>>> >>>>> I can't speak for Paolo, but I've mentioned before that the majority >>>>> of your messages end up in my spam. That's still the case, in fact >>>>> I just marked maybe 10 of them as not spam. >>>>> >>>>> You really need to get this issued sorted out, or you will continue >>>>> to have patches ignore because folks may simply not see them. >>>>> >>>> Hi, >>>> >>>> Thanks for your notice. >>>> >>>> Is it just me or do you see someone else's messages from *huawei.com >>>> end up in spam? I tried to seek help from our IT support, however, they >>>> didn't find anything unusual... >>> >>> So actually I have noticed that a lot of (valid) email from huawei.com (not >>> just you) ends up in the spam mailbox. For me direct messages usually pass >>> (likely matching SPF records for originating mail server save the email >>> from going to spam) but messages going through mailing lists are flagged as >>> spam because the emails are missing valid DKIM signature but huawei.com >>> DMARC config says there should be DKIM signature (even direct messages are >>> missing DKIM so this does not seem as a mailing list configuration issue). >>> So this seems as some misconfiguration of the mails on huawei.com side >>> (likely missing DKIM signing of outgoing email). >> >> SPF/DKIM was indeed a problem earlier for yukaui patches, but I don't >> see that anymore. Maybe it's still an issue for some emails, from them >> or Huawei in general? > > Hum, for me all emails from Huawei I've received even today fail the DKIM > check. After some more digging there is interesting inconsistency in DMARC > configuration for huawei.com domain. There is DMARC record for huawei.com > like: > > huawei.com. 600 IN TXT "v=DMARC1;p=none;rua=mailto:dmarc@edm.huawei.com" > > which means no DKIM is required but _dmarc.huawei.com has: > > _dmarc.huawei.com. 600 IN TXT "v=DMARC1;p=quarantine;ruf=mailto:dmarc@huawei.com;rua=mailto:dmarc@huawei.com" > > which says that DKIM is required. I guess this inconsistency may be the > reason why there are problems with DKIM validation for senders from > huawei.com. Yu Kuai, can you perhaps take this to your IT support to fix > this? Either make sure huawei.com emails get properly signed with DKIM or > remove the 'quarantine' record from _dmarc.huawei.com. Thanks! Of course, I'll try to contact our IT support. Thanks, Kuai > > Honza >
On 5/23/22 7:13 PM, Yu Kuai wrote: > ? 2022/05/23 23:25, Jan Kara ??: >> On Mon 23-05-22 06:36:58, Jens Axboe wrote: >>> On 5/23/22 2:59 AM, Jan Kara wrote: >>>> On Mon 23-05-22 09:10:38, yukuai (C) wrote: >>>>> ? 2022/05/21 20:21, Jens Axboe ??: >>>>>> On 5/21/22 1:22 AM, yukuai (C) wrote: >>>>>>> ? 2022/05/14 17:29, yukuai (C) ??: >>>>>>>> ? 2022/05/05 9:00, yukuai (C) ??: >>>>>>>>> Hi, Paolo >>>>>>>>> >>>>>>>>> Can you take a look at this patchset? It has been quite a long time >>>>>>>>> since we spotted this problem... >>>>>>>>> >>>>>>>> >>>>>>>> friendly ping ... >>>>>>> friendly ping ... >>>>>> >>>>>> I can't speak for Paolo, but I've mentioned before that the majority >>>>>> of your messages end up in my spam. That's still the case, in fact >>>>>> I just marked maybe 10 of them as not spam. >>>>>> >>>>>> You really need to get this issued sorted out, or you will continue >>>>>> to have patches ignore because folks may simply not see them. >>>>>> >>>>> Hi, >>>>> >>>>> Thanks for your notice. >>>>> >>>>> Is it just me or do you see someone else's messages from *huawei.com >>>>> end up in spam? I tried to seek help from our IT support, however, they >>>>> didn't find anything unusual... >>>> >>>> So actually I have noticed that a lot of (valid) email from huawei.com (not >>>> just you) ends up in the spam mailbox. For me direct messages usually pass >>>> (likely matching SPF records for originating mail server save the email >>>> from going to spam) but messages going through mailing lists are flagged as >>>> spam because the emails are missing valid DKIM signature but huawei.com >>>> DMARC config says there should be DKIM signature (even direct messages are >>>> missing DKIM so this does not seem as a mailing list configuration issue). >>>> So this seems as some misconfiguration of the mails on huawei.com side >>>> (likely missing DKIM signing of outgoing email). >>> >>> SPF/DKIM was indeed a problem earlier for yukaui patches, but I don't >>> see that anymore. Maybe it's still an issue for some emails, from them >>> or Huawei in general? >> >> Hum, for me all emails from Huawei I've received even today fail the DKIM >> check. After some more digging there is interesting inconsistency in DMARC >> configuration for huawei.com domain. There is DMARC record for huawei.com >> like: >> >> huawei.com. 600 IN TXT "v=DMARC1;p=none;rua=mailto:dmarc@edm.huawei.com" >> >> which means no DKIM is required but _dmarc.huawei.com has: >> >> _dmarc.huawei.com. 600 IN TXT "v=DMARC1;p=quarantine;ruf=mailto:dmarc@huawei.com;rua=mailto:dmarc@huawei.com" >> >> which says that DKIM is required. I guess this inconsistency may be the >> reason why there are problems with DKIM validation for senders from >> huawei.com. Yu Kuai, can you perhaps take this to your IT support to fix >> this? Either make sure huawei.com emails get properly signed with DKIM or >> remove the 'quarantine' record from _dmarc.huawei.com. Thanks! > Of course, I'll try to contact our IT support. I second that, pretty much every email has been going into spam since, I guess you just had a few lucky ones. Looks like Jan is right, it's a server side configuration error that's causing this, and it's still happening
在 2022/06/01 14:16, Jens Axboe 写道: > On 5/23/22 7:13 PM, Yu Kuai wrote: >> ? 2022/05/23 23:25, Jan Kara ??: >>> On Mon 23-05-22 06:36:58, Jens Axboe wrote: >>>> On 5/23/22 2:59 AM, Jan Kara wrote: >>>>> On Mon 23-05-22 09:10:38, yukuai (C) wrote: >>>>>> ? 2022/05/21 20:21, Jens Axboe ??: >>>>>>> On 5/21/22 1:22 AM, yukuai (C) wrote: >>>>>>>> ? 2022/05/14 17:29, yukuai (C) ??: >>>>>>>>> ? 2022/05/05 9:00, yukuai (C) ??: >>>>>>>>>> Hi, Paolo >>>>>>>>>> >>>>>>>>>> Can you take a look at this patchset? It has been quite a long time >>>>>>>>>> since we spotted this problem... >>>>>>>>>> >>>>>>>>> >>>>>>>>> friendly ping ... >>>>>>>> friendly ping ... >>>>>>> >>>>>>> I can't speak for Paolo, but I've mentioned before that the majority >>>>>>> of your messages end up in my spam. That's still the case, in fact >>>>>>> I just marked maybe 10 of them as not spam. >>>>>>> >>>>>>> You really need to get this issued sorted out, or you will continue >>>>>>> to have patches ignore because folks may simply not see them. >>>>>>> >>>>>> Hi, >>>>>> >>>>>> Thanks for your notice. >>>>>> >>>>>> Is it just me or do you see someone else's messages from *huawei.com >>>>>> end up in spam? I tried to seek help from our IT support, however, they >>>>>> didn't find anything unusual... >>>>> >>>>> So actually I have noticed that a lot of (valid) email from huawei.com (not >>>>> just you) ends up in the spam mailbox. For me direct messages usually pass >>>>> (likely matching SPF records for originating mail server save the email >>>>> from going to spam) but messages going through mailing lists are flagged as >>>>> spam because the emails are missing valid DKIM signature but huawei.com >>>>> DMARC config says there should be DKIM signature (even direct messages are >>>>> missing DKIM so this does not seem as a mailing list configuration issue). >>>>> So this seems as some misconfiguration of the mails on huawei.com side >>>>> (likely missing DKIM signing of outgoing email). >>>> >>>> SPF/DKIM was indeed a problem earlier for yukaui patches, but I don't >>>> see that anymore. Maybe it's still an issue for some emails, from them >>>> or Huawei in general? >>> >>> Hum, for me all emails from Huawei I've received even today fail the DKIM >>> check. After some more digging there is interesting inconsistency in DMARC >>> configuration for huawei.com domain. There is DMARC record for huawei.com >>> like: >>> >>> huawei.com. 600 IN TXT "v=DMARC1;p=none;rua=mailto:dmarc@edm.huawei.com" >>> >>> which means no DKIM is required but _dmarc.huawei.com has: >>> >>> _dmarc.huawei.com. 600 IN TXT "v=DMARC1;p=quarantine;ruf=mailto:dmarc@huawei.com;rua=mailto:dmarc@huawei.com" >>> >>> which says that DKIM is required. I guess this inconsistency may be the >>> reason why there are problems with DKIM validation for senders from >>> huawei.com. Yu Kuai, can you perhaps take this to your IT support to fix >>> this? Either make sure huawei.com emails get properly signed with DKIM or >>> remove the 'quarantine' record from _dmarc.huawei.com. Thanks! >> Of course, I'll try to contact our IT support. > > I second that, pretty much every email has been going into spam since, I > guess you just had a few lucky ones. Looks like Jan is right, it's a > server side configuration error that's causing this, and it's still > happening > Thanks for your response
在 2022/05/23 23:25, Jan Kara 写道: > On Mon 23-05-22 06:36:58, Jens Axboe wrote: >> On 5/23/22 2:59 AM, Jan Kara wrote: >>> On Mon 23-05-22 09:10:38, yukuai (C) wrote: >>>> ? 2022/05/21 20:21, Jens Axboe ??: >>>>> On 5/21/22 1:22 AM, yukuai (C) wrote: >>>>>> ? 2022/05/14 17:29, yukuai (C) ??: >>>>>>> ? 2022/05/05 9:00, yukuai (C) ??: >>>>>>>> Hi, Paolo >>>>>>>> >>>>>>>> Can you take a look at this patchset? It has been quite a long time >>>>>>>> since we spotted this problem... >>>>>>>> >>>>>>> >>>>>>> friendly ping ... >>>>>> friendly ping ... >>>>> >>>>> I can't speak for Paolo, but I've mentioned before that the majority >>>>> of your messages end up in my spam. That's still the case, in fact >>>>> I just marked maybe 10 of them as not spam. >>>>> >>>>> You really need to get this issued sorted out, or you will continue >>>>> to have patches ignore because folks may simply not see them. >>>>> >>>> Hi, >>>> >>>> Thanks for your notice. >>>> >>>> Is it just me or do you see someone else's messages from *huawei.com >>>> end up in spam? I tried to seek help from our IT support, however, they >>>> didn't find anything unusual... >>> >>> So actually I have noticed that a lot of (valid) email from huawei.com (not >>> just you) ends up in the spam mailbox. For me direct messages usually pass >>> (likely matching SPF records for originating mail server save the email >>> from going to spam) but messages going through mailing lists are flagged as >>> spam because the emails are missing valid DKIM signature but huawei.com >>> DMARC config says there should be DKIM signature (even direct messages are >>> missing DKIM so this does not seem as a mailing list configuration issue). >>> So this seems as some misconfiguration of the mails on huawei.com side >>> (likely missing DKIM signing of outgoing email). >> >> SPF/DKIM was indeed a problem earlier for yukaui patches, but I don't >> see that anymore. Maybe it's still an issue for some emails, from them >> or Huawei in general? > > Hum, for me all emails from Huawei I've received even today fail the DKIM > check. After some more digging there is interesting inconsistency in DMARC > configuration for huawei.com domain. There is DMARC record for huawei.com > like: > > huawei.com. 600 IN TXT "v=DMARC1;p=none;rua=mailto:dmarc@edm.huawei.com" > > which means no DKIM is required but _dmarc.huawei.com has: > > _dmarc.huawei.com. 600 IN TXT "v=DMARC1;p=quarantine;ruf=mailto:dmarc@huawei.com;rua=mailto:dmarc@huawei.com" > > which says that DKIM is required. I guess this inconsistency may be the > reason why there are problems with DKIM validation for senders from > huawei.com. Yu Kuai, can you perhaps take this to your IT support to fix > this? Either make sure huawei.com emails get properly signed with DKIM or > remove the 'quarantine' record from _dmarc.huawei.com. Thanks! > > Honza > Hi, Jan and Jens I just got response from our IT support: 'fo' is not set in our dmarc configuration(default is 0), which means SPF and DKIM verify both failed so that emails will end up in spam. It right that DKIM verify is failed because there is no signed key, however, our IT support are curious how SPF verify faild. Can you guys please take a look at ip address of sender? So our IT support can take a look if they miss it from SPF records. Thanks, Kuai
On Tue 07-06-22 11:10:27, Yu Kuai wrote: > 在 2022/05/23 23:25, Jan Kara 写道: > > Hum, for me all emails from Huawei I've received even today fail the DKIM > > check. After some more digging there is interesting inconsistency in DMARC > > configuration for huawei.com domain. There is DMARC record for huawei.com > > like: > > > > huawei.com. 600 IN TXT "v=DMARC1;p=none;rua=mailto:dmarc@edm.huawei.com" > > > > which means no DKIM is required but _dmarc.huawei.com has: > > > > _dmarc.huawei.com. 600 IN TXT "v=DMARC1;p=quarantine;ruf=mailto:dmarc@huawei.com;rua=mailto:dmarc@huawei.com" > > > > which says that DKIM is required. I guess this inconsistency may be the > > reason why there are problems with DKIM validation for senders from > > huawei.com. Yu Kuai, can you perhaps take this to your IT support to fix > > this? Either make sure huawei.com emails get properly signed with DKIM or > > remove the 'quarantine' record from _dmarc.huawei.com. Thanks! > > > > Honza > > > Hi, Jan and Jens > > I just got response from our IT support: > > 'fo' is not set in our dmarc configuration(default is 0), which means > SPF and DKIM verify both failed so that emails will end up in spam. > > It right that DKIM verify is failed because there is no signed key, > however, our IT support are curious how SPF verify faild. > > Can you guys please take a look at ip address of sender? So our IT > support can take a look if they miss it from SPF records. So SPF is what makes me receive direct emails from you. For example on this email I can see: Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-in2.suse.de (Postfix) with ESMTPS id 4LHFjN2L0dzZfj for <jack@suse.cz>; Tue, 7 Jun 2022 03:10:32 +0000 (UTC) ... Authentication-Results: smtp-in2.suse.de; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (smtp-in2.suse.de: domain of yukuai3@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=yukuai3@huawei.com So indeed frasgout.his.huawei.com is correct outgoing server which makes smtp-in2.suse.de believe the email despite missing DKIM signature. But the problem starts when you send email to a mailing list. Let me take for example your email from June 2 with Message-ID <20220602082129.2805890-1-yukuai3@huawei.com>, subject "[PATCH -next] mm/filemap: fix that first page is not mark accessed in filemap_read()". There the mailing list server forwards the email so we have: Received: from smtp-in2.suse.de ([192.168.254.78]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by dovecot-director2.suse.de with LMTPS id 8MC5NfVvmGIPLwAApTUePA (envelope-from <linux-fsdevel-owner@vger.kernel.org>) for <jack@imap.suse.de>; Thu, 02 Jun 2022 08:08:21 +0000 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by smtp-in2.suse.de (Postfix) with ESMTP id 4LDJYK5bf0zZg5 for <jack@suse.cz>; Thu, 2 Jun 2022 08:08:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232063AbiFBIIM (ORCPT <rfc822;jack@suse.cz>); Thu, 2 Jun 2022 04:08:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56178 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232062AbiFBIIL (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>); Thu, 2 Jun 2022 04:08:11 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 75DDB25FE; Thu, 2 Jun 2022 01:08:08 -0700 (PDT) and thus smtp-in2.suse.de complains: Authentication-Results: smtp-in2.suse.de; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=huawei.com (policy=quarantine); spf=pass (smtp-in2.suse.de: domain of linux-fsdevel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-fsdevel-owner@vger.kernel.org Because now we've got email with "From" header from huawei.com domain from a vger mail server which was forwarding it. So SPF has no chance to match (in fact SPF did pass for the Return-Path header which points to vger.kernel.org but DMARC defines that if "From" and "Return-Path" do not match, additional validation is needed - this is the "SPF not aligned (relaxed)" message above). And missing DKIM (the additional validation method) sends the email to spam. Honza
在 2022/06/07 17:54, Jan Kara 写道: > On Tue 07-06-22 11:10:27, Yu Kuai wrote: >> 在 2022/05/23 23:25, Jan Kara 写道: >>> Hum, for me all emails from Huawei I've received even today fail the DKIM >>> check. After some more digging there is interesting inconsistency in DMARC >>> configuration for huawei.com domain. There is DMARC record for huawei.com >>> like: >>> >>> huawei.com. 600 IN TXT "v=DMARC1;p=none;rua=mailto:dmarc@edm.huawei.com" >>> >>> which means no DKIM is required but _dmarc.huawei.com has: >>> >>> _dmarc.huawei.com. 600 IN TXT "v=DMARC1;p=quarantine;ruf=mailto:dmarc@huawei.com;rua=mailto:dmarc@huawei.com" >>> >>> which says that DKIM is required. I guess this inconsistency may be the >>> reason why there are problems with DKIM validation for senders from >>> huawei.com. Yu Kuai, can you perhaps take this to your IT support to fix >>> this? Either make sure huawei.com emails get properly signed with DKIM or >>> remove the 'quarantine' record from _dmarc.huawei.com. Thanks! >>> >>> Honza >>> >> Hi, Jan and Jens >> >> I just got response from our IT support: >> >> 'fo' is not set in our dmarc configuration(default is 0), which means >> SPF and DKIM verify both failed so that emails will end up in spam. >> >> It right that DKIM verify is failed because there is no signed key, >> however, our IT support are curious how SPF verify faild. >> >> Can you guys please take a look at ip address of sender? So our IT >> support can take a look if they miss it from SPF records. > > So SPF is what makes me receive direct emails from you. For example on this > email I can see: > > Received: from frasgout.his.huawei.com (frasgout.his.huawei.com > [185.176.79.56]) > (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 > bits)) > (No client certificate requested) > by smtp-in2.suse.de (Postfix) with ESMTPS id 4LHFjN2L0dzZfj > for <jack@suse.cz>; Tue, 7 Jun 2022 03:10:32 +0000 (UTC) > ... > Authentication-Results: smtp-in2.suse.de; > dkim=none; > dmarc=pass (policy=quarantine) header.from=huawei.com; > spf=pass (smtp-in2.suse.de: domain of yukuai3@huawei.com designates > 185.176.79.56 as permitted sender) smtp.mailfrom=yukuai3@huawei.com > > So indeed frasgout.his.huawei.com is correct outgoing server which makes > smtp-in2.suse.de believe the email despite missing DKIM signature. But the > problem starts when you send email to a mailing list. Let me take for > example your email from June 2 with Message-ID > <20220602082129.2805890-1-yukuai3@huawei.com>, subject "[PATCH -next] > mm/filemap: fix that first page is not mark accessed in filemap_read()". > There the mailing list server forwards the email so we have: > > Received: from smtp-in2.suse.de ([192.168.254.78]) > (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) > by dovecot-director2.suse.de with LMTPS > id 8MC5NfVvmGIPLwAApTUePA > (envelope-from <linux-fsdevel-owner@vger.kernel.org>) > for <jack@imap.suse.de>; Thu, 02 Jun 2022 08:08:21 +0000 > Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) > by smtp-in2.suse.de (Postfix) with ESMTP id 4LDJYK5bf0zZg5 > for <jack@suse.cz>; Thu, 2 Jun 2022 08:08:21 +0000 (UTC) > Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand > id S232063AbiFBIIM (ORCPT <rfc822;jack@suse.cz>); > Thu, 2 Jun 2022 04:08:12 -0400 > Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56178 "EHLO > lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by > vger.kernel.org > with ESMTP id S232062AbiFBIIL (ORCPT > <rfc822;linux-fsdevel@vger.kernel.org>); > Thu, 2 Jun 2022 04:08:11 -0400 > Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) > by lindbergh.monkeyblade.net (Postfix) with ESMTPS id > 75DDB25FE; > Thu, 2 Jun 2022 01:08:08 -0700 (PDT) > > and thus smtp-in2.suse.de complains: > > Authentication-Results: smtp-in2.suse.de; > dkim=none; > dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" > header.from=huawei.com (policy=quarantine); > spf=pass (smtp-in2.suse.de: domain of > linux-fsdevel-owner@vger.kernel.org designates 2620:137:e000::1:20 as > permitted sender) smtp.mailfrom=linux-fsdevel-owner@vger.kernel.org > > Because now we've got email with "From" header from huawei.com domain from > a vger mail server which was forwarding it. So SPF has no chance to match > (in fact SPF did pass for the Return-Path header which points to > vger.kernel.org but DMARC defines that if "From" and "Return-Path" do not > match, additional validation is needed - this is the "SPF not aligned > (relaxed)" message above). And missing DKIM (the additional validation > method) sends the email to spam. Thanks a lot for your analysis, afaics, in order to fix the problem, either your mail server change the configuration to set alignment mode to "relaxed" instead of "strict", or our mail server add correct DKIM signature for emails. I'll contact with our IT support and try to add DKIM signature. Thanks, Kuai
在 2022/06/07 19:51, Yu Kuai 写道: > 在 2022/06/07 17:54, Jan Kara 写道: >> On Tue 07-06-22 11:10:27, Yu Kuai wrote: >>> 在 2022/05/23 23:25, Jan Kara 写道: >>>> Hum, for me all emails from Huawei I've received even today fail the >>>> DKIM >>>> check. After some more digging there is interesting inconsistency in >>>> DMARC >>>> configuration for huawei.com domain. There is DMARC record for >>>> huawei.com >>>> like: >>>> >>>> huawei.com. 600 IN TXT >>>> "v=DMARC1;p=none;rua=mailto:dmarc@edm.huawei.com" >>>> >>>> which means no DKIM is required but _dmarc.huawei.com has: >>>> >>>> _dmarc.huawei.com. 600 IN TXT >>>> "v=DMARC1;p=quarantine;ruf=mailto:dmarc@huawei.com;rua=mailto:dmarc@huawei.com" >>>> >>>> >>>> which says that DKIM is required. I guess this inconsistency may be the >>>> reason why there are problems with DKIM validation for senders from >>>> huawei.com. Yu Kuai, can you perhaps take this to your IT support to >>>> fix >>>> this? Either make sure huawei.com emails get properly signed with >>>> DKIM or >>>> remove the 'quarantine' record from _dmarc.huawei.com. Thanks! >>>> >>>> Honza >>>> >>> Hi, Jan and Jens >>> >>> I just got response from our IT support: >>> >>> 'fo' is not set in our dmarc configuration(default is 0), which means >>> SPF and DKIM verify both failed so that emails will end up in spam. >>> >>> It right that DKIM verify is failed because there is no signed key, >>> however, our IT support are curious how SPF verify faild. >>> >>> Can you guys please take a look at ip address of sender? So our IT >>> support can take a look if they miss it from SPF records. >> >> So SPF is what makes me receive direct emails from you. For example on >> this >> email I can see: >> >> Received: from frasgout.his.huawei.com (frasgout.his.huawei.com >> [185.176.79.56]) >> (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 >> (128/128 >> bits)) >> (No client certificate requested) >> by smtp-in2.suse.de (Postfix) with ESMTPS id 4LHFjN2L0dzZfj >> for <jack@suse.cz>; Tue, 7 Jun 2022 03:10:32 +0000 (UTC) >> ... >> Authentication-Results: smtp-in2.suse.de; >> dkim=none; >> dmarc=pass (policy=quarantine) header.from=huawei.com; >> spf=pass (smtp-in2.suse.de: domain of yukuai3@huawei.com >> designates >> 185.176.79.56 as permitted sender) >> smtp.mailfrom=yukuai3@huawei.com >> >> So indeed frasgout.his.huawei.com is correct outgoing server which makes >> smtp-in2.suse.de believe the email despite missing DKIM signature. But >> the >> problem starts when you send email to a mailing list. Let me take for >> example your email from June 2 with Message-ID >> <20220602082129.2805890-1-yukuai3@huawei.com>, subject "[PATCH -next] >> mm/filemap: fix that first page is not mark accessed in filemap_read()". >> There the mailing list server forwards the email so we have: >> >> Received: from smtp-in2.suse.de ([192.168.254.78]) >> (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 >> bits)) >> by dovecot-director2.suse.de with LMTPS >> id 8MC5NfVvmGIPLwAApTUePA >> (envelope-from <linux-fsdevel-owner@vger.kernel.org>) >> for <jack@imap.suse.de>; Thu, 02 Jun 2022 08:08:21 +0000 >> Received: from out1.vger.email (out1.vger.email >> [IPv6:2620:137:e000::1:20]) >> by smtp-in2.suse.de (Postfix) with ESMTP id 4LDJYK5bf0zZg5 >> for <jack@suse.cz>; Thu, 2 Jun 2022 08:08:21 +0000 (UTC) >> Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand >> id S232063AbiFBIIM (ORCPT <rfc822;jack@suse.cz>); >> Thu, 2 Jun 2022 04:08:12 -0400 >> Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56178 "EHLO >> lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by >> vger.kernel.org >> with ESMTP id S232062AbiFBIIL (ORCPT >> <rfc822;linux-fsdevel@vger.kernel.org>); >> Thu, 2 Jun 2022 04:08:11 -0400 >> Received: from szxga02-in.huawei.com (szxga02-in.huawei.com >> [45.249.212.188]) >> by lindbergh.monkeyblade.net (Postfix) with ESMTPS id >> 75DDB25FE; >> Thu, 2 Jun 2022 01:08:08 -0700 (PDT) >> >> and thus smtp-in2.suse.de complains: >> >> Authentication-Results: smtp-in2.suse.de; >> dkim=none; >> dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" >> header.from=huawei.com (policy=quarantine); >> spf=pass (smtp-in2.suse.de: domain of >> linux-fsdevel-owner@vger.kernel.org designates >> 2620:137:e000::1:20 as >> permitted sender) >> smtp.mailfrom=linux-fsdevel-owner@vger.kernel.org >> >> Because now we've got email with "From" header from huawei.com domain >> from >> a vger mail server which was forwarding it. So SPF has no chance to match >> (in fact SPF did pass for the Return-Path header which points to >> vger.kernel.org but DMARC defines that if "From" and "Return-Path" do not >> match, additional validation is needed - this is the "SPF not aligned >> (relaxed)" message above). And missing DKIM (the additional validation >> method) sends the email to spam. > > Thanks a lot for your analysis, afaics, in order to fix the > problem, either your mail server change the configuration to set > alignment mode to "relaxed" instead of "strict", or our mail server > add correct DKIM signature for emails. > > I'll contact with our IT support and try to add DKIM signature. > > Thanks, > Kuai Hi, Jan Our IT support is worried that add DKIM signature will degrade performance, may I ask that how is your mail server configuation? policy is quarantine or none, and dkim signature is supportted or not. Thanks, Kuai
On Tue 07-06-22 21:06:55, Yu Kuai wrote: > 在 2022/06/07 19:51, Yu Kuai 写道: > > 在 2022/06/07 17:54, Jan Kara 写道: > > > On Tue 07-06-22 11:10:27, Yu Kuai wrote: > > > > 在 2022/05/23 23:25, Jan Kara 写道: > > > > > Hum, for me all emails from Huawei I've received even today > > > > > fail the DKIM > > > > > check. After some more digging there is interesting > > > > > inconsistency in DMARC > > > > > configuration for huawei.com domain. There is DMARC record > > > > > for huawei.com > > > > > like: > > > > > > > > > > huawei.com. 600 IN TXT > > > > > "v=DMARC1;p=none;rua=mailto:dmarc@edm.huawei.com" > > > > > > > > > > which means no DKIM is required but _dmarc.huawei.com has: > > > > > > > > > > _dmarc.huawei.com. 600 IN TXT "v=DMARC1;p=quarantine;ruf=mailto:dmarc@huawei.com;rua=mailto:dmarc@huawei.com" > > > > > > > > > > > > > > > which says that DKIM is required. I guess this inconsistency may be the > > > > > reason why there are problems with DKIM validation for senders from > > > > > huawei.com. Yu Kuai, can you perhaps take this to your IT > > > > > support to fix > > > > > this? Either make sure huawei.com emails get properly signed > > > > > with DKIM or > > > > > remove the 'quarantine' record from _dmarc.huawei.com. Thanks! > > > > > > > > > > Honza > > > > > > > > > Hi, Jan and Jens > > > > > > > > I just got response from our IT support: > > > > > > > > 'fo' is not set in our dmarc configuration(default is 0), which means > > > > SPF and DKIM verify both failed so that emails will end up in spam. > > > > > > > > It right that DKIM verify is failed because there is no signed key, > > > > however, our IT support are curious how SPF verify faild. > > > > > > > > Can you guys please take a look at ip address of sender? So our IT > > > > support can take a look if they miss it from SPF records. > > > > > > So SPF is what makes me receive direct emails from you. For example > > > on this > > > email I can see: > > > > > > Received: from frasgout.his.huawei.com (frasgout.his.huawei.com > > > [185.176.79.56]) > > > (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 > > > (128/128 > > > bits)) > > > (No client certificate requested) > > > by smtp-in2.suse.de (Postfix) with ESMTPS id 4LHFjN2L0dzZfj > > > for <jack@suse.cz>; Tue, 7 Jun 2022 03:10:32 +0000 (UTC) > > > ... > > > Authentication-Results: smtp-in2.suse.de; > > > dkim=none; > > > dmarc=pass (policy=quarantine) header.from=huawei.com; > > > spf=pass (smtp-in2.suse.de: domain of yukuai3@huawei.com > > > designates > > > 185.176.79.56 as permitted sender) > > > smtp.mailfrom=yukuai3@huawei.com > > > > > > So indeed frasgout.his.huawei.com is correct outgoing server which makes > > > smtp-in2.suse.de believe the email despite missing DKIM signature. > > > But the > > > problem starts when you send email to a mailing list. Let me take for > > > example your email from June 2 with Message-ID > > > <20220602082129.2805890-1-yukuai3@huawei.com>, subject "[PATCH -next] > > > mm/filemap: fix that first page is not mark accessed in filemap_read()". > > > There the mailing list server forwards the email so we have: > > > > > > Received: from smtp-in2.suse.de ([192.168.254.78]) > > > (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 > > > bits)) > > > by dovecot-director2.suse.de with LMTPS > > > id 8MC5NfVvmGIPLwAApTUePA > > > (envelope-from <linux-fsdevel-owner@vger.kernel.org>) > > > for <jack@imap.suse.de>; Thu, 02 Jun 2022 08:08:21 +0000 > > > Received: from out1.vger.email (out1.vger.email > > > [IPv6:2620:137:e000::1:20]) > > > by smtp-in2.suse.de (Postfix) with ESMTP id 4LDJYK5bf0zZg5 > > > for <jack@suse.cz>; Thu, 2 Jun 2022 08:08:21 +0000 (UTC) > > > Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand > > > id S232063AbiFBIIM (ORCPT <rfc822;jack@suse.cz>); > > > Thu, 2 Jun 2022 04:08:12 -0400 > > > Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56178 "EHLO > > > lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by > > > vger.kernel.org > > > with ESMTP id S232062AbiFBIIL (ORCPT > > > <rfc822;linux-fsdevel@vger.kernel.org>); > > > Thu, 2 Jun 2022 04:08:11 -0400 > > > Received: from szxga02-in.huawei.com (szxga02-in.huawei.com > > > [45.249.212.188]) > > > by lindbergh.monkeyblade.net (Postfix) with ESMTPS id > > > 75DDB25FE; > > > Thu, 2 Jun 2022 01:08:08 -0700 (PDT) > > > > > > and thus smtp-in2.suse.de complains: > > > > > > Authentication-Results: smtp-in2.suse.de; > > > dkim=none; > > > dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" > > > header.from=huawei.com (policy=quarantine); > > > spf=pass (smtp-in2.suse.de: domain of > > > linux-fsdevel-owner@vger.kernel.org designates > > > 2620:137:e000::1:20 as > > > permitted sender) > > > smtp.mailfrom=linux-fsdevel-owner@vger.kernel.org > > > > > > Because now we've got email with "From" header from huawei.com > > > domain from > > > a vger mail server which was forwarding it. So SPF has no chance to match > > > (in fact SPF did pass for the Return-Path header which points to > > > vger.kernel.org but DMARC defines that if "From" and "Return-Path" do not > > > match, additional validation is needed - this is the "SPF not aligned > > > (relaxed)" message above). And missing DKIM (the additional validation > > > method) sends the email to spam. > > > > Thanks a lot for your analysis, afaics, in order to fix the > > problem, either your mail server change the configuration to set > > alignment mode to "relaxed" instead of "strict", or our mail server > > add correct DKIM signature for emails. > > > > I'll contact with our IT support and try to add DKIM signature. > > > > Thanks, > > Kuai > > Hi, Jan > > Our IT support is worried that add DKIM signature will degrade > performance, may I ask that how is your mail server configuation? policy > is quarantine or none, and dkim signature is supportted or not. The DMARC policy (relaxed / quarantine) is not configured on the side of the receiving mail server but on huawei.com side. As I wrote above it is this DMARC record in DNS of huawei.com domain that makes receiving mail servers refuse the email without DKIM signature (if SPF does not match): _dmarc.huawei.com. 600 IN TXT "v=DMARC1;p=quarantine;ruf=mailto:dmarc@huawei.com;rua=mailto:dmarc@huawei.com" So if your IT admins do not want to introduce DKIM signatures on outgoing email, they should set policy to 'p=none' in the DMARC DNS record to tell that fact to receiving mail servers. Honza