[Mailman-Users] Digest always in MIME
Hi all I can't get my digests to be sended in other than MIME although Plain Text is selected. Any way to get this solved ? I have access to the server if any CLI need to be used. I'm running 2.1.11 Thanks and Regards -- Matthieu HUTIN Ceux qui ne luttent pas contre le mal, finissent par le servir -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Digest always in MIME
Matthieu HUTIN wrote: I can't get my digests to be sended in other than MIME although Plain Text is selected. Any way to get this solved ? I have access to the server if any CLI need to be used. I'm running 2.1.11 Check the messages in the digest, as well as the digest header and footer. I'm willing to bet that there is a character set or content-transfer-encoding difference somewhere in there, which is forcing the MIME formatting. -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Digest always in MIME
Matthieu HUTIN wrote: I've done a test by sending an email myself. I always send email as plain test (I hate HTMl in mails ;-) ) So it should have been digested as plain texte according to my setup. However I may be wrong as this is the first time i'm facing this issues. It's been working perfectly for the past 5 years with older mailman versions (2.1.5 was the last version I used without problems). You sent a text/plain, but you used iso-8859-1 as your character set, and you included binary characters. That got encoded as quoted-printable when it was sent, and that was preserved when the message was transmitted back out. Now, I'm not an expert in the workings of the underlying MIME or e-mail library code in Python that is used by Mailman, but I suspect that any non-USASCII characters in any of the input messages will force all the digests to be processed as MIME and not plain text. Unfortunately, for a language like French, that poses a problem since there are so many accents you have to account for. Now, Python is written by a very international community speaking many, many different languages, and to a somewhat lesser degree the same is true of Mailman. So, we are very sensitive to language and character set problems and we do everything we can to try to avoid causing problems for anyone else. But that means we *don't* take a just send eight approach to transmitting messages, and instead we actually try to Do The Right Thing. Unfortunately, sometimes not everyone agrees on what that Right Thing is. Unfortunately, we really don't have all the information here that we need. We do see that the outgoing message gets wrapped up in a multipart/mixed, but we don't see what might have caused that to happen. I will also add that qmail is not one of my favourite MTAs, because I've seen more than a few problems caused by it (and I'm not very popular amongst the qmail communities). But I'm also aware that plenty of sites out there are using qmail on a daily basis without any problems, so I won't even talk about pointing the finger that direction until we've eliminated all other likely possibilities. If you want to send me a complete, unredacted copy of the message in question (with all headers intact), I'll be glad to take a look at it for you and see if I can spot anything obvious. Alternatively, if you like I can subscribe to your liste and we can try out some things that way. All I ask is that you keep in mind that I don't speak or read French, despite of the fact that I lived in Belgium for nearly eight years and my wife and I moved back to the US just a couple years ago. -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Configure Repy-To header for confirmations
Dennis Putnam wrote; I am having a problem getting the reply-to header configured for confirmations. Due to some email restrictions from my ISP I cannot use the default (i.e. [EMAIL PROTECTED]). Thus when a user tries to reply to a confirmation, it bounces (it needs to be [EMAIL PROTECTED]).I can't find this in the documentation (probably because my reply-to search key word keeps yielding user reply information not mailman generated reply-to forms). How to I configure the reply-to header for confirmations. Do I need to customize the form itself? Thanks. Can you use [EMAIL PROTECTED] or does that have to be munged too? If you can use it, set VERP_CONFIRMATIONS = Yes in mm_cfg.py and restart Mailman. If the list-confirm address is munged too, you will have to modify the definitions of the getListAddress() and GetConfirmEmail() methods in Mailman/MailList.py to return the addresses you use. Also, if you are concerned about the site (mailman) list, you need to modify the get_site_email() function in Mailman/Utils.py. If you need help with these mods, post again and indicate which of the nine list-... addresses need to be munged and to what. -- Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Digest always in MIME
Brad Knowles wrote: Matthieu HUTIN wrote: I can't get my digests to be sended in other than MIME although Plain Text is selected. Any way to get this solved ? I have access to the server if any CLI need to be used. I'm running 2.1.11 Check the messages in the digest, as well as the digest header and footer. I'm willing to bet that there is a character set or content-transfer-encoding difference somewhere in there, which is forcing the MIME formatting. I don't think that would do it. Those things should be recoded or scrubbed. When you say Plain Text is selected, do you mean When receiving digests, which format is default on the admin Digest options page? If so, that only controls the default setting for new list members. Each existing member has an individual setting for Get MIME or Plain Text Digests on the user options page which reflected by the presence or absence of a check in the box in the plain column on the admin Membership List pages. -- Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Configure Repy-To header for confirmations
Thanks for the reply. OK, to be clear the problem is one of mailbox name length. Another list member replied privately and questioned that so I will repost that information here. The number characters in my list name plus the '-request' is 6 characters too many. I could change the list names but that would be too much effort for list members most of which are computer illiterate. These lists have been around for several years. The need for confirmations simply has not come up until now. It probably never worked from the beginning. It has been so long since I set these up I'm not sure I remember how (IIRC, that can be set on a list-by-list basis from the web interface) but obviously this is different. Perhaps I should have pointed that out in the original question but I didn't think it was really relevant. That being said, using list-confirm is still that same length. As for what needs to be munged, I think only the confirmation message. My list members don't use anything else and probably wouldn't know how anyway. In all the years these lists have been active, this is the first time someone had to change their email address so it is the first time a confirmation was needed. I was not aware this was going to be a major effort. Be aware that, although I am experienced with many various languages (scripting and otherwise), python is not among them. Mark Sapiro wrote: Dennis Putnam wrote; I am having a problem getting the reply-to header configured for confirmations. Due to some email restrictions from my ISP I cannot use the default (i.e. [EMAIL PROTECTED]). Thus when a user tries to reply to a confirmation, it bounces (it needs to be [EMAIL PROTECTED]).I can't find this in the documentation (probably because my reply-to search key word keeps yielding user reply information not mailman generated reply-to forms). How to I configure the reply-to header for confirmations. Do I need to customize the form itself? Thanks. Can you use [EMAIL PROTECTED] or does that have to be munged too? If you can use it, set VERP_CONFIRMATIONS = Yes in mm_cfg.py and restart Mailman. If the list-confirm address is munged too, you will have to modify the definitions of the getListAddress() and GetConfirmEmail() methods in Mailman/MailList.py to return the addresses you use. Also, if you are concerned about the site (mailman) list, you need to modify the get_site_email() function in Mailman/Utils.py. If you need help with these mods, post again and indicate which of the nine list-... addresses need to be munged and to what. signature.asc Description: OpenPGP digital signature -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Configure Repy-To header for confirmations
Dennis Putnam wrote: OK, to be clear the problem is one of mailbox name length. Another list member replied privately and questioned that so I will repost that information here. The number characters in my list name plus the '-request' is 6 characters too many. I could change the list names but that would be too much effort for list members most of which are computer illiterate. These lists have been around for several years. The need for confirmations simply has not come up until now. It probably never worked from the beginning. It has been so long since I set these up I'm not sure I remember how (IIRC, that can be set on a list-by-list basis from the web interface) but obviously this is different. Perhaps I should have pointed that out in the original question but I didn't think it was really relevant. That being said, using list-confirm is still that same length. As for what needs to be munged, I think only the confirmation message. Still, if you can use VERP_CONFIRMATIONS, it would make the code modifications simpler because of the way the address is generated. The difference is without VERP_CONFIRMATIONS, the message is From: [EMAIL PROTECTED] with Subject: confirm xx... and with VERP_CONFIRMATIONS it is From [EMAIL PROTECTED] with Subject: Your confirmation is required to ... Of course, if the local part suffix is included in the length restriction, this only makes it worse and can't be used. My list members don't use anything else and probably wouldn't know how anyway. In all the years these lists have been active, this is the first time someone had to change their email address so it is the first time a confirmation was needed. I was not aware this was going to be a major effort. Be aware that, although I am experienced with many various languages (scripting and otherwise), python is not among them. Does the munging need to be done for all lists in the installation? Is it done in the same way for each list? I.e. is list-request always mapped to listreq or does the mapping vary depending on list. Can the mapping be deduced programmatically, or would it have to be looked up in a table? -- Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Configure Repy-To header for confirmations
Mark Sapiro wrote: Still, if you can use VERP_CONFIRMATIONS, it would make the code modifications simpler because of the way the address is generated. The difference is without VERP_CONFIRMATIONS, the message is From: [EMAIL PROTECTED] with Subject: confirm xx... and with VERP_CONFIRMATIONS it is From [EMAIL PROTECTED] with Subject: Your confirmation is required to ... Of course, if the local part suffix is included in the length restriction, this only makes it worse and can't be used. Since I don't know what the implications of VERP_CONFIRMATIONS are, I have reason to not try it. :) The length restriction is on the mailbox name or rather the user name (everything that precedes the '@'). Does the munging need to be done for all lists in the installation? Is it done in the same way for each list? I.e. is list-request always mapped to listreq or does the mapping vary depending on list. Can the mapping be deduced programmatically, or would it have to be looked up in a table? Actually no. There is only 1 list that otherwise exceeds this limit. The mapping can be deduced programmatically. It is simply the list name prepended to 'req' rather than prepended to '-request'. signature.asc Description: OpenPGP digital signature -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] message delivery eating disk space ..
Well, I noticed that there are files in the : /var/lib/mailman/data/bounce-events-*.pck where * are numbers .. considering their sizes (3-50MBs) they aren't that bad but with time, they pile up and fill the disk space.. is it safe to delete these files? Thanks.. Date: Fri, 31 Oct 2008 11:28:29 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; mailman-users@python.org Subject: Re: [Mailman-Users] message delivery eating disk space .. faisal anif wrote: is there a kind of temporary files that mailman doesn't cleanup? what can I do? No. The only files are the queue files which hold the message as it is processed and the archives. The queue files are removed when message processing is complete. As Brad says, you need to actually check to see which directory hierarchy was using up the disk space? -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Configure Repy-To header for confirmations
Dennis Putnam wrote: Mark Sapiro wrote: Still, if you can use VERP_CONFIRMATIONS, it would make the code modifications simpler because of the way the address is generated. The difference is without VERP_CONFIRMATIONS, the message is From: [EMAIL PROTECTED] with Subject: confirm xx... and with VERP_CONFIRMATIONS it is From [EMAIL PROTECTED] with Subject: Your confirmation is required to ... Of course, if the local part suffix is included in the length restriction, this only makes it worse and can't be used. Since I don't know what the implications of VERP_CONFIRMATIONS are, I have reason to not try it. :) The implication is exactly what I said above. The aditional implication is that a reply which is addressed to [EMAIL PROTECTED] has to be delivered the same as if it were addressed to [EMAIL PROTECTED] The length restriction is on the mailbox name or rather the user name (everything that precedes the '@'). Since Mailman doesn't use mailbox delivery, why do you have an issue with these names at all? Does the munging need to be done for all lists in the installation? Is it done in the same way for each list? I.e. is list-request always mapped to listreq or does the mapping vary depending on list. Can the mapping be deduced programmatically, or would it have to be looked up in a table? Actually no. There is only 1 list that otherwise exceeds this limit. The mapping can be deduced programmatically. It is simply the list name prepended to 'req' rather than prepended to '-request'. I'm not convinced you even need to do this. How does your MTA actually deliver to Mailman? -- Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Configure Repy-To header for confirmations
Mark Sapiro wrote: Dennis Putnam wrote: The implication is exactly what I said above. The aditional implication is that a reply which is addressed to [EMAIL PROTECTED] has to be delivered the same as if it were addressed to [EMAIL PROTECTED] Then that won't work either. Since Mailman doesn't use mailbox delivery, why do you have an issue with these names at all? I don't have a static IP. I have to create mailboxes on my ISP's server. Then use fetchmail to retrieve the messages. This means the mailbox has to be pre-defined to my ISP then I have fetchmail map that to the actual list mailbox in mailman. I'm not convinced you even need to do this. How does your MTA actually deliver to Mailman? The MTA that delivers to mailman is postfix but as I said above, the issue is that I have to use fetchmail. As far as mailman is concerned it is indeed going to list-request so the actual address used by list members is transparent to mailman. That is why I need to munge the Reply-To header for confirmations. signature.asc Description: OpenPGP digital signature -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] message delivery eating disk space ..
faisal anif wrote: Well, I noticed that there are files in the : /var/lib/mailman/data/bounce-events-*.pck where * are numbers .. considering their sizes (3-50MBs) they aren't that bad but with time, they pile up and fill the disk space.. is it safe to delete these files? They should not be accumulating. There should never be more than 2, or if you run multiple sliced qrunners, never more than the number of OutgoingRunner slices + BounceRunner slices. See http://mail.python.org/pipermail/mailman-users/2008-October/063746.html for a recent post with more detail. -- Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
