On 24/03/2021 13.55, Gerhard Sittig wrote:
There is a recent(?) climb in the number of messages where the
headers look like this:
| From: A user's name via sigrok-devel <sigrok-devel@lists.sourceforge.net>
| To: sigrok-devel@lists.sourceforge.net
| Subject: [sigrok-devel] some subject
| Reply-To: user's name again <u...@example.com>
Which is so totally wrong. For those who are not fluent in the
interpretation of email headers:
- The sender pretends to be the list. Which is not true. Could be
seen as impersonating somebody else, to gain some benefit.
- The sender requests(!) that responses go to his private
account. Which excludes all other subscribers. Unless the
responding person is extra careful, and undoes the broken setup
of the sender's transmission. (Requires spotting the issue in
the first place. Adding extra work to the process of responding
in a useful manner. Reducing the willingness to do that again
as the broken condition becomes more and more popular.)
...
...
What's the origin of that stupid and unsocial email setup which
results in the violation of the mailing list's foundation? Is
this some extra popular mail user agent while its authors just
are not aware? Is it a service provider doing stupid things? Was
kind of shocked to see that even git-send-email(1) traffic was
affected. Which makes me suspect that it's an ISP or mail
provider playing games.
Can the source of this problem get identified, which makes the
affected senders look bad without their even being aware? And can
it get fixed? So that useful and helpful list communication is
possible, instead of ending up in a maze of personal service
requests and a deserted list?
The ISP manipulated(?) git commit transmission even results in a
total misattribution of the work that the submitter has spent on
an issue, trying to help the project. Which isn't desirable
either, for several reasons. Also adds extra work on those who
try to accept this contribution, again reducing the odds of
seeing it happen. The time could have been spent on something
useful instead.
I've seen it as well...
I don't think that users do this in bad intent.
It is perfectly legal to address a mailing list with Reply To set...
Actually I think that it is a problem with the different MUA mail clents
that the users have... and how the (broken) MUAs behave..
Different MUAs have different approaches on how to conclude that the
email is from a mailing list and that the replies should go to the list
and not the originating user
I did som tests on hitting Reply and Reply-All on a mailinglist email
entry in some of the more popular MUA mail clients ThunderBird, OutLook,
OutLook 365 - and they more or less did different things (based looking
at different attrs in the email header)
Looking after List-Post: is one of them... but different MUAs do
different things - so stripping the Reply To may be the only way to
control the mailflow from a central point...
The SF mailinglist should be able to remove the "Reply To:" - and if
configured so - add its own. It is not a requirement that the mailing
list adds its own Reply To - but it is ofent seen that the mailinglist
removes any existing Reply To and add their to prevent broken mailing
clients (MUAs) from replying directly to the originating user...
All mailinglist managers (that I know of) can do that - including the
"MailMan" that SF.net uses...
The problem here can be that the "Reply To:" can be included into the
DMARC signature so removing the "Reply To:" from the header may make
DMARC checks think that the message is fake... :-/
This is one of the latest challenges for mailing lists not to manipulate
the messages so much that DMARC fails...
But on the other hand the SF mailinglist inserts both a subject prefix
and a header - and SF seems to add its own DMARC signature - so is
should be legal for it to also remove the "Reply To:"...
Maybe you should ask the SF-mailinglist-support-team how to remove Reply
To sigrok-devel mailing-list...
/Uffe
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
