header field: Sender
![](https://secure.gravatar.com/avatar/046d814b682f472d47d53ce7bfa8f02c.jpg?s=120&d=mm&r=g)
Dear friends,
one question. If the Sender-field exist and mailman create a new Sender-field-line, then he have to delete the old one, or not?
And maybe, this is true also for all other header fields, what mailman create?
many greetings, willi St. Elena de Uairen, Venezuela
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 3/27/16 10:08 AM, willi uebelherr wrote:
one question. If the Sender-field exist and mailman create a new Sender-field-line, then he have to delete the old one, or not?
Yes, Mailman deletes any existing Sender: headers before adding one.
And maybe, this is true also for all other header fields, what mailman create?
Some yes and some no. E.g. Errors-To: will be replaced. Depending on list settings, a new, merged, Reply-To: or Cc: will be created and the original replaced, but headers like X-BeenThere: X-Mailman-Version:, etc., will just be added.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
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).
![](https://secure.gravatar.com/avatar/046d814b682f472d47d53ce7bfa8f02c.jpg?s=120&d=mm&r=g)
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:
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 3/30/16 12:46 AM, willi uebelherr wrote:
In Mailman 2.1.14 and newer, there is an include_sender_header setting on each list's General Options page. If that is Yes, Mailman will remove all Sender: headers from the incoming mail and add its own. If it is No, Mailman doesn't remove or add Sender: headers. Pre 2.1.14 Mailman always did removal and addition.
There is also an Errors-To: header and there should always be just Mailman's.
If Mailman is adding a Sender: header without first removing any existing ones, I would like to see all the headers from such a message as sent by Mailman.
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.
Bugs in MM 2.1 should be reported at <https://bugs.launchpad.net/mailman/+filebug>, but first, just send me or post here the full message headers from the message as sent by Mailman.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/046d814b682f472d47d53ce7bfa8f02c.jpg?s=120&d=mm&r=g)
Dear Mark,
i am so happy about your strong cooperation. it is fantastic.
Here i will show you some of the header. The mailman version is not included. And you see, that the administrators of this list don´t understand the difference from ...-request and ...-bounces.
Reply-To: joly@punkcast.com Sender: joly.nyc@gmail.com In-Reply-To: <56FCB7A8.3080706@apc.org> References: <56FCB7A8.3080706@apc.org> From: Joly MacFie <joly@punkcast.com> Errors-to: bestbits-owner@lists.bestbits.net Sender: bestbits-request@lists.bestbits.net List-Id: <bestbits.lists.bestbits.net>
In other emails it is listed similar. Therefore, i tried with the Field List-Id. In my filter i use now two filter criteria in OR relation. Sender or List-Id. Never i found a doubled entry List-Id.
And now it is stable working. After some time, i will try List-Id alone. I think, it is better then both. And yes, Errors-to is the same. But i like more List-Id.
many, many thanks for your time, work and friendly helping. with greetings, willi St. Elena de uairen, Venezuela
Am 30.03.2016 um 09:44 schrieb Mark Sapiro:
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 3/31/16 10:34 AM, willi uebelherr wrote:
i am so happy about your strong cooperation. it is fantastic.
That's what we're here for. We want to help.
This mailman installation has non-standard patches/code.
In standard GNU Mailman, both Errors-To: and Sender: as added by Mailman will be to the listname-bounces address. Here they go to -owner and -request respectively, so the most likely explanation for multiple Sender: headers is the installation's modified code doesn't remove the Sender: headers before adding its own.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 3/27/16 10:08 AM, willi uebelherr wrote:
one question. If the Sender-field exist and mailman create a new Sender-field-line, then he have to delete the old one, or not?
Yes, Mailman deletes any existing Sender: headers before adding one.
And maybe, this is true also for all other header fields, what mailman create?
Some yes and some no. E.g. Errors-To: will be replaced. Depending on list settings, a new, merged, Reply-To: or Cc: will be created and the original replaced, but headers like X-BeenThere: X-Mailman-Version:, etc., will just be added.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
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).
![](https://secure.gravatar.com/avatar/046d814b682f472d47d53ce7bfa8f02c.jpg?s=120&d=mm&r=g)
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:
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 3/30/16 12:46 AM, willi uebelherr wrote:
In Mailman 2.1.14 and newer, there is an include_sender_header setting on each list's General Options page. If that is Yes, Mailman will remove all Sender: headers from the incoming mail and add its own. If it is No, Mailman doesn't remove or add Sender: headers. Pre 2.1.14 Mailman always did removal and addition.
There is also an Errors-To: header and there should always be just Mailman's.
If Mailman is adding a Sender: header without first removing any existing ones, I would like to see all the headers from such a message as sent by Mailman.
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.
Bugs in MM 2.1 should be reported at <https://bugs.launchpad.net/mailman/+filebug>, but first, just send me or post here the full message headers from the message as sent by Mailman.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/046d814b682f472d47d53ce7bfa8f02c.jpg?s=120&d=mm&r=g)
Dear Mark,
i am so happy about your strong cooperation. it is fantastic.
Here i will show you some of the header. The mailman version is not included. And you see, that the administrators of this list don´t understand the difference from ...-request and ...-bounces.
Reply-To: joly@punkcast.com Sender: joly.nyc@gmail.com In-Reply-To: <56FCB7A8.3080706@apc.org> References: <56FCB7A8.3080706@apc.org> From: Joly MacFie <joly@punkcast.com> Errors-to: bestbits-owner@lists.bestbits.net Sender: bestbits-request@lists.bestbits.net List-Id: <bestbits.lists.bestbits.net>
In other emails it is listed similar. Therefore, i tried with the Field List-Id. In my filter i use now two filter criteria in OR relation. Sender or List-Id. Never i found a doubled entry List-Id.
And now it is stable working. After some time, i will try List-Id alone. I think, it is better then both. And yes, Errors-to is the same. But i like more List-Id.
many, many thanks for your time, work and friendly helping. with greetings, willi St. Elena de uairen, Venezuela
Am 30.03.2016 um 09:44 schrieb Mark Sapiro:
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 3/31/16 10:34 AM, willi uebelherr wrote:
i am so happy about your strong cooperation. it is fantastic.
That's what we're here for. We want to help.
This mailman installation has non-standard patches/code.
In standard GNU Mailman, both Errors-To: and Sender: as added by Mailman will be to the listname-bounces address. Here they go to -owner and -request respectively, so the most likely explanation for multiple Sender: headers is the installation's modified code doesn't remove the Sender: headers before adding its own.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Mark Sapiro
-
Stephen J. Turnbull
-
willi uebelherr