qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Ed Swierk <eswierk@skyportsystems.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Jason Wang <jasowang@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PULL 00/18] Net patches
Date: Mon, 8 Jan 2018 10:33:15 -0600	[thread overview]
Message-ID: <eeb7de3f-5b0f-0c64-7e31-62d6bb046b9a@redhat.com> (raw)
In-Reply-To: <CAO_EM_=NgT1f+bM7_2ztw1S0ZvkDYZyJjwvRMWV6FVyvODMWfA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4369 bytes --]

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.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

  reply	other threads:[~2018-01-08 16:33 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-22  2:15 [Qemu-devel] [PULL 00/18] Net patches Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 01/18] e1000, e1000e: Move per-packet TX offload flags out of context state Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 02/18] e1000: Separate TSO and non-TSO contexts, fixing UDP TX corruption Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 03/18] net: move CRC32 calculation from compute_mcast_idx() into its own net_crc32() function Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 04/18] net: introduce net_crc32_le() function Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 05/18] pcnet: switch pcnet over to use net_crc32_le() Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 06/18] eepro100: switch eepro100 e100_compute_mcast_idx() over to use net_crc32() Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 07/18] sunhme: switch sunhme over to use net_crc32_le() Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 08/18] sungem: fix multicast filter CRC calculation Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 09/18] eepro100: use inline net_crc32() and bitshift instead of compute_mcast_idx() Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 10/18] opencores_eth: " Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 11/18] lan9118: " Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 12/18] ftgmac100: " Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 13/18] ne2000: " Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 14/18] rtl8139: " Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 15/18] net: remove unused compute_mcast_idx() function Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 16/18] net: Remove the legacy "-net channel" parameter Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 17/18] qemu-doc: The "-net nic" option can be used with "netdev=...", too Jason Wang
2017-12-22  2:15 ` [Qemu-devel] [PULL 18/18] qemu-doc: Update the deprecation information of -tftp, -bootp, -redir and -smb Jason Wang
2018-01-08 10:16 ` [Qemu-devel] [PULL 00/18] Net patches Peter Maydell
2018-01-08 13:30   ` Ed Swierk
2018-01-08 15:10     ` Eric Blake
2018-01-08 15:18       ` Eric Blake
2018-01-08 15:25         ` Eric Blake
2018-01-08 15:54       ` Ed Swierk
2018-01-08 16:33         ` Eric Blake [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-09-08  2:05 Jason Wang
2017-09-08 13:00 ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eeb7de3f-5b0f-0c64-7e31-62d6bb046b9a@redhat.com \
    --to=eblake@redhat.com \
    --cc=eswierk@skyportsystems.com \
    --cc=jasowang@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).