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.