Re: [nmh-workers] FSF is changing Mailman list settings unless you opt out (fwd)

[Steffen Nurpmeso]

Ken Hornstein wrote in <address@hidden>:
 |>Yuck.  As a purely rhetorical note, do they have a plan to upgrade
 |>from the TLS 1.0 they use.  (And i hope this does not qualify as
 |>sexual harassment.  It is not!  I eat at home, like the Beatles.)
 |
 |I ... do not know about the TLS 1.0 issues, nor do I see how it's relevant
 |to this discussion.

I am sorry, i was in galop and you had to suffer the consequences.
It was also not meant to address you as "you", it is just that
i always hit "r" and if there is no reply-to: or mail-followup-to:
then the list is not the sole receiver.

I am not a cryptographer therefore i also do not know about TLS
1.0 issues, except .. that diediedie IETF draft, that the money
changers deprecated it to June 2018 at latest, and that the big
companies deprecate it (and the different/newer 1.1) in
.. spring (?) next year.  And that i really would like to slim my
vserver ssl/tls conf.  (eggs.gnu.org is the _only_ mail service
that i know that uses TLS1.0:DHE_RSA_AES_256_CBC_SHA1;
i accidentally stumbled over this a few months ago, when looking
into my archives.)

And it is entirely unrelated to this thread of course.
I personally feel sad because of the direction all this goes to.
That From: rewriting is just sick, it makes me sick.  Thank you.
RFC 4871 on DKIM says at least

   A common practice among systems that are primarily redistributors of
   mail is to add a Sender header field to the message, to identify the
   address being used to sign the message.  This practice will remove
   any preexisting Sender header field as required by [RFC2822].  The
   forwarder applies a new DKIM-Signature header field with the
   signature, public key, and related information of the forwarder.

whereas the Yahoo! only RFC 7489 says

   It has been suggested in several message authentication efforts that
   the Sender header field be checked for an identifier of interest, as
   the standards indicate this as the proper way to indicate a
   re-mailing of content such as through a mailing list.

   1.  The main user protection approach is to be concerned with what
       the user sees when a message is rendered.  There is no consistent
       behavior among MUAs regarding what to do with the content of the
       Sender field, if present.  Accordingly, supporting checking of
       the end user might never actually see, which can create a vector
       for attack against end users by simply forging a Sender field
       containing some identifier that DMARC will like.

For the MUA i maintain they at least can when they want.
What the .... is that?  People are too stupid to get this
additional field right (look who they are voting!), so lets just
not even consider this.
This goes in line with the web browser community, they also do not
get it right and do not show TLS status, content blocking, Unicode
related lookalike thingies, or any such stuff.  No, not me,
Yahoo!, this is too exhausting, and i do not have any control over
it!!

   2.  Although it is certainly true that this is what the Sender field
       is for, its use in this way is also unreliable, making it a poor
       candidate for inclusion in the DMARC evaluation algorithm.

They break a field already present in RFC 822 from 1982.  That is
certainly true.  They should just have followed the RFCs and maybe
adjusted From: to also include the list address, then resign it
(maybe), moving the original author to Sender:.  Maybe.  But hey
the job is done, maybe they got a bonus.  Sounds bitter.  Baeh.

Good night from Germany.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)