Subject: [TOOLS-DEVELOPMENT] DMARC status (was Re: Tools Call Agenda -- 8 May 2018 at 1:00 Eastern)

From: Alexey Melnikov <[email-masked]>
Date: Tue, 08 May 2018 15:04:41 +0100

Hi all,

On Thu, Apr 26, 2018, at 9:48 PM, Russ Housley wrote:

> 4. Server Infrastructure
>    - IESG discussions of DMARC -- Henrik and Alexey
>      -- Deployed for volunteer WGs.  Is it ready for all mail lists?

My summary of the current DMARC workaround state is as follows:

1) DMARC workaround code works, in particular:

a) messages from p=reject domains are rewritten, so that they have @dmarc.ietf.org From email addresses.
b) replying to such mapped email addresses works
c) I haven't seen any DMARC related bounces in response to email sent from mapped @dmarc.ietf.org addresses.
d) The message duplicate problem was solved, as well as the temporary message loss that was experienced a week ago.
e) It is hard to assess how much "addressbook pollution"(*) we get from @dmarc.ietf.org addresses. I wish I knew answer to this question, but this is rather Mail User Agent specific.

2) It is possible to send an email to an algorithmically constructed @dmarc.ietf.org address even if the email address from which it was constructed doesn't come from p=reject DMARC domain. In fact, the original email doesn't even have to be a subscriber of an IETF mailing list (Henrik, is this correct?). This is effectively an obscure form of an open relay, so we need to fix that. Henrik has a proposal how to fix that.

Preventing the open relay problem was not clearly specified in requirements for Henrik's work, we only realized that this is a problem very recently. A fix proposed by Henrik will change the mapping, so it will invalidate all already instantiated mapped addresses @dmarc.ietf.org. Henrik will correct me, but I think this means that replies to them will bounce. I suggest if we want to change the format, we change it now before deploying DMARC workaround to more mailing lists. This will minimize the number of complains that people will have about bounces.

3) I've sent a separate email saying that in order to be able to move to ARC (which is a better fix), we should keep ability to control which IETF mailing lists are subject to DMARC workaround. This is trivial, we just need not to forget to preserve this.

Best Regards,
Alexey

(*) - i.e. emails from "mapped(A)" (where "A" is an email address from a p=reject  DMARC domain) might appear in recipients addressbooks together or instead of email address "A".

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 8 May 2018 17:47:25 +0200

Supplementary info inline:

On 2018-05-08 16:04, Alexey Melnikov wrote:
> 2) It is possible to send an email to an algorithmically constructed
> @dmarc.ietf.org address even if the email address from which it was
> constructed doesn't come from p=reject DMARC domain. In fact, the
> original email doesn't even have to be a subscriber of an IETF
> mailing list (Henrik, is this correct?).

Yes, that's right.

> This is effectively an
> obscure form of an open relay, so we need to fix that. Henrik has a
> proposal how to fix that.
> 
> Preventing the open relay problem was not clearly specified in
> requirements for Henrik's work, we only realized that this is a
> problem very recently. A fix proposed by Henrik will change the
> mapping, so it will invalidate all already instantiated mapped
> addresses @dmarc.ietf.org. Henrik will correct me, but I think this
> means that replies to them will bounce.

Yes.

> I suggest if we want to
> change the format, we change it now before deploying DMARC workaround
> to more mailing lists. This will minimize the number of complains
> that people will have about bounces.
> 
> 3) I've sent a separate email saying that in order to be able to move
> to ARC (which is a better fix), we should keep ability to control
> which IETF mailing lists are subject to DMARC workaround. This is
> trivial, we just need not to forget to preserve this.

Ack.  This is a config setting for the dmarc rewrite workaround.

Best regards,

	Henrik

---

From: Robert Sparks <[email-masked]>
Date: Tue, 8 May 2018 11:27:04 -0500

Things have worked out such that I wont be able to join today’s call (i’m fine, its travel related). Apologies for the last minute notice. 

Sent from my iPhone

> On May 8, 2018, at 10:47 AM, Henrik Levkowetz <[email-masked]> wrote:
> 
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 8 May 2018 18:49:35 +0200

Some late notes:

On 2018-04-26 22:48, Russ Housley wrote:
> Tools Call Agenda -- 8 May 2018 at 1:00 Eastern
> 
> 
> JOIN WEBEX MEETING
> https://ietf.webex.com/ietf/j.php?MTID=m440dd848726339c03e605b9956e38bac
> Meeting number (access code): 640 103 570
> Meeting password: tools
> 
> JOIN BY PHONE
> 1-877-668-4493 Call-in toll free number (US/Canada) 
> 1-650-479-3208 Call-in toll number (US/Canada)
> Meeting number (access code): 640 103 570
> Meeting password: tools
> 
> 
> 1. Datatracker Projects
>    - Expected Datatracker Releases -- Robert and Henrik
>      -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan

This has been adjusted to match the expected GDPR work.

>    - GDPR Compliance -- Robert and Henrik

5 of 8 work items are done; this covers most of the datatracker model and
infrastructure changes.  What remains is mostly GUI-related.  Should be
done within about a week; release before the GDPR May 25th deadline should
be easy.

> 2. Community & Other Projects
>    - Discontinue MonArch email archives -- Robert
>      -- Community clearly still likes MonArch speed

Ryan has made good progress on static mailarchive.ietf.org pages with
CDN support.  Gives a definitely snappy feel.  Ryan can say more.

> 3. RFC Services Projects
>    - RFC Format Contracts -- Heather and Robert
>      -- IDnits
>      -- Publication Formatter
>      -- Text Submission
>      -- RFClint
>      -- SVGcheck
>      -- XMLdiff
> 
> 4. Server Infrastructure

Alexey sent a separate note about the current status.

	Henrik

> 5. Parking Lot
>    - Prepare the RFC Production Center code for publication
> 
> 6. AOB
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 8 May 2018 12:50:33 -0400

Alexey:

I do not think we need to wait for the open relay fix before deploying to all mail lists.  Do you agree?

Russ

> On May 8, 2018, at 10:04 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 08 May 2018 17:54:35 +0100

Russ,

> to all mail lists.  Do you agree?

I don't agree.

I am Ok with having open relay as long as it is fixed quickly. So we can deploy without the fix, as long as the mapping format is changed before we deploy to all mail lists. However, once the format is changed, I think Henrik will be nearly done with the fix anyway.

---

From: Russ Housley <[email-masked]>
Date: Tue, 8 May 2018 13:01:11 -0400

> On May 8, 2018, at 12:54 PM, Alexey Melnikov <[email-masked]> wrote:
> 
> Russ,
> 

So, you do agree about the open relay part, right?

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 8 May 2018 13:34:04 -0400

Based on the discussion during the Tools Call today, no format change is needed.  A check for IETF mail list membership will be added, and then we will deploy on Thursday.  Alexey will announce to the community.

Russ

> On May 8, 2018, at 12:50 PM, Russ Housley <[email-masked]> wrote:
> 
> Alexey:
>

---

From: Ryan Cross <[email-masked]>
Date: Wed, 9 May 2018 12:51:01 -0700

All,

The latest version of the mail archive is available here:
http://mailarchivetest.ietf.org/arch/ <http://mailarchivetest.ietf.org/arch/>

The contents are not current, but a snapshot from April.  There is a new Settings menu on the top of the page.  Here you can turn Legacy mode on or off.  When legacy mode is on the user will be directed to MHonArc like pages when browsing a list by date or by thread.  These pages are cached by CloudFlare.  The URL scheme is date based, one month of messages per page.  For example:
http://mailarchivetest.ietf.org/arch/browse/static/ietf/2018-04/ <http://mailarchivetest.ietf.org/arch/browse/static/ietf/2018-04/>

For lists with less volume, less than 750 messages a year, index pages are consolidated by year.  For example:
http://mailarchivetest.ietf.org/arch/browse/static/nemo/2009/ <http://mailarchivetest.ietf.org/arch/browse/static/nemo/2009/>

The user can edit the URL to jump to a particular date.  Client side redirects are used when needed to map between year / month pages, based on the rules above.

Please take a look and reply with any comments or feedback.

Thank You,
Ryan

> On Apr 26, 2018, at 1:48 PM, Russ Housley <[email-masked]> wrote:
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 9 May 2018 23:28:55 +0200

Hi Alexey,

I've released postconfirm 0.42.0 with the added check on sender for the
dmarc reverse path, and installed the new version on mail.ietf.org.

Best regards,

	Henrik

On 2018-05-08 19:34, Russ Housley wrote:
> Based on the discussion during the Tools Call today, no format change
> is needed. A check for IETF mail list membership will be added, and
> then we will deploy on Thursday. Alexey will announce to the
> community.
> 
> Russ
>