Re: DMARC: perspectives from a listadmin of large open-source lists

[Hector Santos <[e-mail]>]

By far, the list REPLY-TO feature benefited the layman list user 
inability to figure it out how to reply back to the list by 
manipulating header input fields with the lack of MUA support for a 
3rd reply button:

    REPLY
    REPLY TO ALL
    REPLY TO LIST  <--- NEW

With greater support for LIST-* headers, the MUA can now add the 3rd 
button and the default, natural "reply" action to reply back to the list.

Without it, most layman and even "lazy" veterans can mistakenly and 
naturally click that "reply" button only to unintentionally go 
directly and not to the groupware discussion area A.K.A "mailing list."

You have to look at it from the perspective of the UI ERGONOMICS and 
the support process why it even existed.

That said, it is not natural to TAMPER with mail, especially of the 
body text, but including headers that were not created by the middle 
ware.  However, there has been a historical school of though that 
mailing list server/agent was acting as a NEW MAIL AUTHOR.  I didn't 
think it was 100% kolsher, but it was a rationale for the technical 
justification to tamper with mail; list software is really a "new 
author" therefore it has "right" to tamper with mail.

I didn't generally agree with this, but even our own (commercial) 
Mailing List Server does manipulate the headers in principle to 
improve communications, and of recent as an option to improve DKIM 
resigning logical "faults."

Improving the communications included:

   - Prepare the BOUNCE, ERROR address.  Different remote
     Bouncing software behave differently in how or where
     they get the bounce or error address.  So this one reason
     you will have redundancy, changes in error addresses;
     Sender:, Errors-To: to target all forms.

   - Minimizing mistakes, making it easy for the USER to
     have a "natural" reply back to the list by adjusting
     the Reply-To header.  By far, the preferred intention is
     to reply back to the list.  Newer MUA with list-* header
     and "REPLY TO LIST"  reduces the new to set or strip &
     replace the reply-to field.

There was also major concerns with DKIM tampering with originality. 
It will be an injustice to try to cover, go over all that again here.

Finally, this whole discussion about DMARC is all deja-vu and surreal 
too that the OP is concern now when DKIM with SSP or ADSP had the same 
problems and DMARC does not resolve it.  He knows that. So I see this 
as a marketing effort to push something that clearly will not work for 
the same reasons ADSP did not. Its no different.

In principle, we will always have the same problems with LIST software 
because of the mindset and rationale that the middle ware is a "new 
author" and therefore does not have to respect any SECURITY POLICY 
controls by the originating, authoring, copyright holding domain.  It 
was a clear case of intentional ignorance (don't recognize ADSP, make 
it historic) and tampering of a email security control.

It was the reason the powerful concept of SSP/ADSP did not get the 
wider MARKETING endorsement it deserved.   The main hurdle was with 
LIST systems.

The same problem will be with DMARC.  There is nothing that DMARC can 
do to change that except perhaps advocate (and document) stronger 
middle ware controls to properly follow these security controls.

But you can't have this when DKIM was revised to be based on a 
futuristic, never materializing 3rd party signer control system that 
is consistent and persistent from point to point, end to end, pretty 
much like the SSL/BROWSER market with each browser supporting the same 
3rd party signature framework.  We can not repeat this in the mail 
system -- too  many vendors to begin with. With browsers, there were 
only a few you had to deal with.

We knew all this list problem in DKIM 101. It was part of the original 
charter that any idea to make it work would be secondary to the 
primary purpose of gaining stronger direct domain security controls. 
DKIM and ASDP were part of the original standard track charter.  It 
made perfect engineering sense.

But that seem to change by the "big" list operators who felt that DKIM 
needs be a 3rd PARTY signer control framework with less recognition to 
the original author. SSP which has 3rd party controls was reduced to 
ADSP that allowed for a secured 1st party control.  But that still 
would not work with LIST system unless these middle ware routers 
supports the 1st party controls too.

It was too easy to see that it won't work.  Not thru LIST systems 
without 100% advocated support for honoring these new domain security 
protocol policies.  Instead, it is documented in DKIM related RFCs 
that its OK to tamper with mail as long it was resigned with "trusted" 
3rd party signing domains.  The theory is that if the receivers also 
had a table of the same 3rd party Trusted signers, then it would 
resolve the broken chain of trusted mail problem.

We can't have it both ways.

---
HLS

On 4/8/2014 1:16 AM, Robin H. Johnson wrote:
> On Tue, Apr 08, 2014 at 06:06:27AM +0100, Sabahattin Gucukoglu wrote:
>> On 8 Apr 2014, at 05:21, John R Levine <[e-mail]> wrote:
>>> Mailing list apps can't "implement DMARC" other than by getting rid
>>> of every feature that makes lists more functional than simple
>>> forwarders. Given that we haven't done so for any of the previous
>>> FUSSPs that didn't contemplate mailing lists, because those features
>>> are useful to our users, it seems unlikely we'll do so now.
>> Well,  Mailman 2.1.16 has the FROM_IS_LIST feature that "Fixes" the
>> problem by putting the list address in the From: field.  That seems to
>> work, except that you lose information (the sender's address) if the
>> list wants to operate a policy of "Reply goes to list".  You can then
>> assure that DKIM signatures are valid and set up SPF, etc.  This also
>> has the effect of letting you operate through the various cloud email
>> platforms that try to validate sender addresses.
> This breaks the ability to reply directly to the sender when the
> response should NOT be on the list, as well as the ability to put a
> sender in a personal killfile.
>
> And don't start on suggesting Reply-To instead, RFC 2822 already
> noted that it should be set by the author, not the list software [1].
>
> [1] http://marc.merlins.org/netrants/listreplyto.html List Reply-To
> considered harmful.
>