Subject: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Jan 2017 11:57:37 +0000

Dear tools team,

The IESG continues to be concerned about the impacts of growing usage of
DMARC technology on IETF discussion lists. All choices in front of us,
including not taking any action, cause some pain, as we have not been
able to identify a perfect approach to mitigate the impacts.

The situation is evolving, as email software evolves and new features
relating to DMARC also continue to be developed. The IESG believes that
we need to be aware of the effects and consider different mitigation
approaches. The effects are not necessarily easy to predict based on
theoretical analysis, given the wide variety of software and
configurations that our participants use, and their personal preferences
among important IETF mailing list functions and avoidance of various
failure modes.

Robert told us that Mailman is due for an upgrade in February. This
upgrade would allow IETF to run different IETF mailing lists in
different configurations. The IESG would
like to perform limited tests on selected lists to determine the impacts
of a couple of different possible mitigation configurations. It is
important that such an experiment be carefully monitored and that the
impacted users be asked about their experiences. There are strong
opinions on this matter, but the discussion of this matter has so far
involved a small subset of vocal IETFers. What matters more though is
the experience of the users as a whole.

The two options that IESG would like to test are: From header field
rewriting ([email-masked] would become an IETF managed forwarding
alias,
the exact structure is TBD(*)) and message wrapping (encapsulation of
original message inside multipart/mixed, with the original message as
message/rfc822 attachment + some explanatory text). 
These workarounds would only apply to email messages from domains that
publish DMARC p=reject or p=quarantine policy. Messages from domains
that don't publish DMARC policy or have DMARC policy p=none are not
affected by this change.

In order to figure out which option has less impact on IETF
participants, IESG would like to try one of them for a couple of weeks
(+ collect feedback), roll back the configuration to the current one,
then try the other one (+collect feedback) for a couple of weeks.
Each experiment will run on one or more IETF mailing list.

In order to achieve this, the IESG would like to do the following:

0) Publish detailed description of how two workarounds are going to work
and comparison of their side effects (both positive and negative).

1) Decide with the tools team which mailing lists to use for testing
of each option. This will also need to be agreed with managers/working
group chairs
of the affected mailing lists.

2) Discuss with the tools team what kind of changes (new scripts,
reconfiguration, Mailman options) are needed to deploy both of these.
Agree on when they can be implemented. Publish the timeline to the wider
IETF community.

3) Design with the tools team a detailed plan of what kind of feedback
we will be looking for when evaluating results of experimental
deployment
of each of these options. Notify the IETF community.

4) It might be worth publishing a Wiki page describing how different
email clients, email systems can be used or configured to minimize
impact of workarounds.

Does this look like a reasonable starting plan?

Best Regards,
Alexey, on behalf of IESG

(*) For example, [email-masked] would become [email-masked] and
any email sent to [email-masked] would be forwarded to
[email-masked].
We are still discussing with Email experts how forwarding emails might
look
like. Some possibilites are u=[email-masked],
[email-masked].

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 23 Jan 2017 17:54:29 +0100

Hi Alexey,

On 2017-01-23 12:57, Alexey Melnikov wrote:
> different configurations.

I guess this is coupled with upgrading to OpenSUSE 42.x and gives us
Mailman 2.1.18 (or higher) with the DMARC handling options described
here: , yes?

https://wiki.list.org/DEV/DMARC

> The IESG would

If the features of Mailman 2.1.18 are insufficient, the start-up time
(writing new scripts) will be longer than otherwise.  This should maybe
be factored into any decision on exactly which options to try out.

FWIW, based on what I can read out of the available mailman 2.1
documentation (http://www.list.org/mailman-admin.txt) the From: header
field rewriting considered above isn't supported by mailman directly;
only replacement of the From: header value with the list address (for
p=reject or p=quarantine domains) and placement of the original From:
address in Reply-To:.  So it looks as if the rewrite test option _will_
require both new coding and consideration of where in the email pipeline
the rewrite (and rewrite reversal) should be done.

> Does this look like a reasonable starting plan?

Assuming that we can use mailman 2.1.18 features to do the rewriting/
wrapping, then yes, as far as I can see.  If new code is required, it's
still reasonable if the time and resources issue is considered.

> [email-masked].

I'm sure the experts will provide a good suggestion.  I just note that of
the options above, the 'u=[email-masked]' variant will
not be able to handle addresses like [email-masked]
(multiple dots in either localpart or domain -- which dot corresponds to
the at sign when you reverse the address??) well if you expect to do the
reversal without using saved state.

Best regards,

	Henrik

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 24 Jan 2017 19:22:55 +0000

Hi Henrik,

> On 23 Jan 2017, at 16:54, Henrik Levkowetz <[email-masked]> wrote:
> 
> Hi Alexey,
> 

I believe so.

> be factored into any decision on exactly which options to try out.

Right. From address rewriting will need some scripting work. John Levine said that he could help (he done a version in Python for his mailing list manager, which is not Mailman).

> the rewrite (and rewrite reversal) should be done.

Right.

> reversal without using saved state.

Right, this was just from the top of head. I don't think we want to maintain any state for this. Some kind of encoding scheme would be needed. Possibly replacing @ with %.

Best Regards,
Alexey