Dear Mark and Stephan and friends,
yes, i absolutly trust you that you work in relation to the RFC´s definition. And, it is truth, that i am not an expert in the email transport mechanism.
My second question was more to understand the background. And i am very thankful for the answer from Mark.
But the answer to the first question is not correct. I have some people in different mailman maillists with 2 Sender fields. And because my mail client Thunderbird use the first then the filter don´t work. I had to extend the filterlist with the "Sender" field.
Maybe, i can also use the field "List-Id". It can work for the same. And in all this mails with the double Sender field i see only one List-Id fields.
Never i have checked other mails for 2 Sender fields. I can do it, if it would helpful for you. And if you need the mailman version, i will look for.
In this moment, i don´t know, how i can search with Thunderbird for 2 Sender fields. But this is a totally other question.
If i should make a bug report, tell me. And, because it is the first time for me, give me some tips how i should do it.
many greetings, willi St. Elena de Uairen, Venezuela Am 29.03.2016 um 13:28 schrieb Stephen J. Turnbull:
Mark Sapiro writes: > Some yes and some no. As Mark knows, the general rule is that with a few deliberate, documented, optional cases Mailman tries to strictly respect RFC constraints for fields defined in an RFC. We're pretty good about that; if you're not cranky RFC pedant like me, don't bother checking. But if you notice something that doesn't work as the RFCs specify, consider it a bug and notify us (especially in Mailman 3!) (Do check that it's not an optional behavior -- Reply-To munging and From munging are non-conforming but options have been provided because there is "sufficient reason" for doing so. If you don't like it, you'll have to take it up with the list owner, not with us.) > Depending on list settings, a new, merged, Reply-To: or Cc: will be > created and the original replaced, Also From may be munged to disable DMARC, depending on list settings and possibly a DNS check for DMARC policy. > but headers like X-BeenThere: X-Mailman-Version:, etc., will just > be added. BTW, in my (recent) experience Mailman 2 does not handle List-Post and List-ID correctly. It replaces them, but List-Post should be left alone, and a new List-ID field should be added when there is already one, and if the existing List-ID is not a parent list, then it should be removed. https://gitlab.com/mailman/mailman/issues/217 for Mailman 3. @Mark: I don't think this is worth fixing for Mailman 2, but if you want to have it fixed, or just want an issue to document the lack of conformance that you can close, let me know and I'll file one. If you want help on a fix, I'll be happy to work with you (but not until late April). ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/willi.uebelherr%40gmail.com
------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
