qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 00/18] Net patches


From: Eric Blake
Subject: Re: [Qemu-devel] [PULL 00/18] Net patches
Date: Mon, 8 Jan 2018 10:33:15 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

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: <address@hidden>
> 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 <address@hidden>

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: <address@hidden>
> 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 <address@hidden>

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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]