DMARC and Reply-to munging

[taggart]

We are seeing a weird corner case, when the "reply_to_header" setting is set to "list" and dmarc_protection_mode is on (we're using "dmarc_reject,dmarc_quarantine") then Reply-to is getting set to the original sender rather than the list. I think the "reply_to_header" setting should have precedent over the DMARC stuff.

We are seeing this on 6.1, I haven't tried to repeat on 6.2 but it should be easy to test.

[ikedas]

Hi @taggart,

Could you please check also 6.2? There seems difference between 6.1 and 6.2 (former modifys Reply-To after DMARC protection, OTOH latter does in reversed order).

Additionally, the behavior seems to be changed by forced subparameter of reply_to_header list parameter. Please check it together.

[taggart]

Yes, I have also seen that "forced" makes it use the list and that "respect" uses the DMARC setting. MY guess is that the DMARC is munging earlier in the process and that when the list specific setting is checked it sees the Reply-to that the DMARC munging added and treats it the same as one added by a users MUA. Some options:

0. maybe it's doing the correct thing already, it is respecting the Reply-to (that was silently added by the DMARC protection, hmm I guess if an MUA adds a Reply-to that might get stomped?)
1. it could check if the header looks like it's been DMARC munged and leave it alone
2. the DMARC munging could set some additional hint that the list specific check could look for
3. the DMARC munging could happen after the list specific check. this might be more correct, but maybe more surprising to the user?

[ikedas]

Although it's a bit verbose, I'll write what Sympa does.

Description below is based on Sympa 6.2.24. Sympa 6.1.x may behave reversed order, i.e. processes 2., then 1.

---

1. If there is no Reply-To: field, or reply_to_header.apply is forced:

   • If reply_to_header.value is list:

     Overwrite Reply-To: by list address.

   • If reply_to_header.value is sender:

     Overwrite Reply-To: by original sender.

   • If reply_to_header.value is all:

     Overwrite Reply-To: by list address and original sender.

   • If reply_to_header.value is other_email:

     Overwrite Reply-To: by value of reply_to_header.other_email.

   Otherwise, keep Reply-To: (and Resent-Reply-To: if any) fields.

   (See _twist() in Sympa::Spindle::TransformOutgoing.)

2. If dmarc_protecion.mode is set:

   • If dmarc_protecion.mode includes all, or

   • dmarc_protecion.mode includes dkim_signature and DKIM-Signature: field exists, or

   • dmarc_protecion.mode includes domain_regex and original sender matches with dmarc_protecion.domain_regex:

     Munge "from header" (see below).

   Otherwise if original From: field exists, and dmarc_protecion.mode includes either dmarc_reject, dmarc_any or dmarc_quarantine:

   • If dmarc_protecion.mode includes dmarc_reject and DMARC policy of recipient domain is p=reject, or

   • dmarc_protecion.mode includes dmarc_quarantine and DMARC policy of recipient domain is p=quarantine, or

   • dmarc_protecion.mode includes dmarc_any:

     Append X-Original-DMARC-Record: field, and
     Munge "from header" (see below).

   To munge "from header", anonymous address is chosen as:

   • If message is bound for owner (LIST-request) or moderator (LIST-editor) address:

     Anonymous address is that address.

   • else if dmarc_protecion.other_email is set:

     Anonymous address is value of dmarc_protecion.other_email.

   • otherwise:

     Anonymous address is list address.

   then,

   • If Reply-To: field does not exist:

     Append Reply-To: field with original value of From: field.

   and, append X-Original-From: field.

   and finally, replace From: field with anonymous address.

   (See dmarc_protect() in Sympa::Message.)

---

[ikedas]

@taggart, are these right?

• On Sympa 6.1 (processes 2. then 1. in comment above), in following condition:

  1. Original message does not have Reply-To: header,
  2. dmarc_protection.mode is set,
  3. dmarc_protection.mode does not match with recipient domain (e.g. dmarc_protection.mode is dmarc_quarantine and policy of recipient domain is p=quarantine),
  4. reply_to_header.apply is respect (not forced),

  Reply-To: field will be added with originator address as a value.

• This seems not the case of Sympa 6.2 (processes 1. then 2. in comment above).

[ikedas]

Hi @taggart,

Do you think that the problem was solved on 6.2.x? (Unfortunately, there is no plan to fix 6.1.x).

[ikedas]

Hi @taggart,

Can we close this issue, or discuss further on this issue?

[ikedas]

Closed by now.