[Mailman-Users] header field: Sender

[willi uebelherr]

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 at 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
>