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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <johnl@xxxxxxxxx> 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.







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]