RE: DMARC methods in mailman

["Christian Huitema" <[e-mail]>]

On Wednesday, December 21, 2016 7:12 AM, Theodore Ts'o wrote:

>On Wed, Dec 21, 2016 at 01:10:16PM +0100, Philip Homburg wrote:
>> ...
>> 
>> Or are you saying that at the moment 40% of the subscribers of IETF lists
reject
>> or otherwise not receive mail from DMARC protected senders?
>
> It's much more likely that this is the percentage of subscribers that
> are sending from domains that are claiming a DMARC policy.  What's
> interesting is how few of these domains are actually *following* the
> DMARC specification in rejecting, unconditionally, e-mails which fail
> the DMARC checks.

I think that Ted is making a very strong point here. For the IETF mailing
list, the problem does not start when some company publishes a DMARC
"p=reject" policy. The problem occurs when some mail providers decides to
unconditionally bounce messages. These bounces are causing mail to be lost,
and subscribers to be disconnected from mailing list.

We have at least one big provider, Gmail, implementing a sane compromise:
reject the email if you do not have reasons to otherwise trust it. That is,
use some logic instead of bone headed unconditional behavior. From a user
point of view, that may mean having to fish specify that they "trust
[e-mail]", maybe after fishing some messages out of the spam
folder. Not great, but much more light weight than most of the proposed
alternatives. So, in short, we have a solution with demonstrated working
code.

Maybe the IETF should document this expected behavior as part of the mailing
list submission process. "If you want to participate in the IETF, your mail
provider should allow you to receive messages from the IETF."

-- Christian Huitema