Ken Hornstein wrote in <20190926174635.3b44384...@pb-smtp20.pobox.com>: |>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) -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers