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
>
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: j...@punkcast.c
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 th
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 M
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 both
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 he
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
---
