header field: Sender
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
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
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).
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%40gmai...
On 3/30/16 12:46 AM, willi uebelherr wrote:
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.
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.
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.
There is also an Errors-To: header and there should always be just Mailman's.
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.
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
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:
On 3/30/16 12:46 AM, willi uebelherr wrote:
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.
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.
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.
There is also an Errors-To: header and there should always be just Mailman's.
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.
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.
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.
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>
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