Re: [Mailman-Users] delivery off
Mark Sapiro ha scritto: Manlio Perillo wrote: As a response to the set show command, I obtain: delivery off (a causa degli errori il Wed, 12 Apr 2006 01:21:46 -) cause of errors on I've tried to send a delivery on command, but this seems not to work. What's the problem? Did you include a set authenticate your member password preceding the set delivery on command? The first time no! But I do this later, without effects. Maybe I have to unsubscribe/subscribe? Thanks and regards Manlio Perillo -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
On Thu, 2006-04-27 at 22:46 -0500, Brad Knowles wrote: If the previous value of the Sender: field is being lost, then that should be corrected. At the very least, the value should be saved in an Old-Sender: or Previous-Sender: or some other suitable renamed sender field. Probably Original-Sender: -Barry signature.asc Description: This is a digitally signed message part -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] delivery off
Manlio Perillo wrote: But I do this later, without effects. Do you get any reply at all to your email? Maybe I have to unsubscribe/subscribe? Can you visit your options page on the web and set delivery on there? -- 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://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] delivery off
Mark Sapiro ha scritto: Manlio Perillo wrote: But I do this later, without effects. Do you get any reply at all to your email? Yes: - Risultati: Impostata opzione delivery - Finito. - Results: delivery option set - End. But a later set show gave always delivery off. Maybe I have to unsubscribe/subscribe? Can you visit your options page on the web and set delivery on there? I've already solved by unsubscribe/subscribe. I still don't understand the problem. Mailman tried to send a response to my (ISP) MTA and failed? Thanks and regards Manlio Perillo -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] Headers
I apologize if this has been asked before, but I have googled day in and day out so, if you could point me in the right direction: All digests include the email information for each email such as: Message: 1 Date: Tue, 25 Apr 2006 09:57:37 -0400 From: Apache [EMAIL PROTECTED] Subject: Status- Client, Demo To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] We are using our lists in an automated method, therefore it will always be generated from an automated source so this information is irrelevant and over the course of a digest with 200+ emails it adds up to be alot of unnecessary overhead. Where can I go to remove it. Even if it is a global change. I was poking around in the Handlers Directory, but am not sure if there is a better place to do this. Thanks in advance for your expert advice. Louis Meunier MIS Career Connections 169 Central Ave Albany, NY 12206 p.518.689.2148 f.518.689.2385 -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] delivery off
Manlio Perillo wrote: But a later set show gave always delivery off. snip I still don't understand the problem. Mailman tried to send a response to my (ISP) MTA and failed? Maybe these are related. What are the bounce settings for the list? Does disable occur on the first bounce? Berhaps the MTA is reporting some status that Mailman thinks is a bounce so your subscription is enabled and then the reply to your commands bounces and you are disabled again. Check both Mailman's bounce and smtp-failure logs. -- 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://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Headers
Louis M. wrote: All digests include the email information for each email such as: snip Where can I go to remove it. Even if it is a global change. see the mm_cfg.py options MIME_DIGEST_KEEP_HEADERS and PLAIN_DIGEST_KEEP_HEADERS (described in Defaults.py). -- 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://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
On 4/28/06 6:06 AM, Barry Warsaw [EMAIL PROTECTED] wrote: On Thu, 2006-04-27 at 22:46 -0500, Brad Knowles wrote: If the previous value of the Sender: field is being lost, then that should be corrected. At the very least, the value should be saved in an Old-Sender: or Previous-Sender: or some other suitable renamed sender field. Probably Original-Sender: Probably, indeed. But what happens if that header was already taken in the process that brought the message to mailman for distribution to the list? (As usual, I have only questions, not answers.) --John -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-cabal] Cannot update Mailman FAQ
At 12:04 PM -0400 2006-04-28, Barry Warsaw wrote: That's fine. I'm not going to worry about changing that, since at some point the FAQ should be moved to the new Wiki. (Any volunteers?) The current FAQ Wizard has the advantage of simplicity and tracking all previous changes (in case things need to be rolled back). Wikis, by their nature, are considerably more complex and at least some of them don't track changes. I'm not really looking forward to having all the FAQ stuff moved over to the wiki. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-cabal] Cannot update Mailman FAQ
On Fri, 2006-04-28 at 12:37 -0500, Brad Knowles wrote: The current FAQ Wizard has the advantage of simplicity and tracking all previous changes (in case things need to be rolled back). Wikis, by their nature, are considerably more complex and at least some of them don't track changes. I'm not really looking forward to having all the FAQ stuff moved over to the wiki. Confluence tracks changes too, just not in RCS! Yes, the wiki will be a bit more complex, but I think by not much and hopefully the benefits will outweigh the added complexity. The real advantage is that we'll have one less place where our artifacts live (and one less system to maintain -- remember during the last Python system move the FAQ wizard got lost in the shuffle for a while). I'd like to at least /attempt/ to put a FAQ in the wiki. If it really sucks, we'll deal with it then. -Barry signature.asc Description: This is a digitally signed message part -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
John W. Baxter wrote: Probably, indeed. But what happens if that header was already taken in the process that brought the message to mailman for distribution to the list? As I noted in my previous response, I believe that the correct field (if Mailman were to add a Sender: header) to add would be Resent-Sender. Please see RFC 2822, section 3.6.6. The Resent-Sender field may be multivalued, so this isn't a problem. However, Mailman should not be modifying the Sender: field at all. Original-Sender is a header used when gatewaying X.400 messages into RFC 822 messages for use in JNT mail networks. It would not be appropriate for use here. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
Don't forget to consider things like SPF, which I think uses the sender field. Whatever is used for SPF _must_ be the domain of the mailman box, or you're gonna run into a pack of trouble. ...Trouble similar to a current problem I am having with AOL: they are bouncing all email with the FROM: address of a specific AOL user, when mailman delivers the messages to -any- aol or cs.com address. Its a very bad problem, because AOL is saying its a SPF problem, when it clearly isn't (as other aol people can post to the list and receive their posts), and all the aol users are being automatically unsubscribed from lists that this guy posts on. But I digress... Bob Neal Groothuis wrote: It does not appear that Mailman modifies the Sender: field to comply with RFC 2822. The list-bounces address is not the mailbox of the agent responsible for transmitting the message, as required in section 3.6.2. The mailbox of the agent responsible for the transmission of the message would be the list-owner address. Mailman's use the Sender: field does not seem to be in line with the intent of the RFC, nor with current usage of the field. snip -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Sender field
On 2006-04-27 at 22:46-05 Brad Knowles [EMAIL PROTECTED] wrote: At 10:40 AM -0500 2006-04-27, Neal Groothuis wrote: Again from RFC 2822 3.6.2, the Sender: header should contain the address of the agent responsible for transmitting the message, meaning that a person who sends mail to the address in that header should expect to reach said agent, not suggest to Mailman that a message bounced. Right. Mailman is the agent responsible for transmitting the message, and this needs to be reflected. This is not correct. Quoting RFC2822 section 3.6.2: 3.6.2. Originator fields The originator fields indicate the mailbox(es) of the source of the message. The From: field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The Sender: field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the Sender: field and the mailbox of the actual author would appear in the From: field. The Sender header should be employed by the orignator of the message, and only the originator. Mailman is not the originator of a message sent to a list; it is merely a relay agent. I will grant that the phrasing of the RFC is suboptimal here--it uses transmission when a better word choice would have been submission. But the immediately proceeding example (of a secretary sending mail on behalf of another person) clarifies the intent beyond any claim of ambiguity. [Outlook's behavior] is an MUA problem. See FAQ 2.3. No, it's not. As much as it pains me to say it, Outlook's behavior matches perfectly the intent of the RFC. It is Mailman's behavior of rewriting the Sender header that is the problem. However, we want to make sure to capture any potential messages that may be routed to the Sender: field and have them automatically processed through the part of the system that is designed to do that sort of thing. Mailman's processing behavior is to treat a reply to the Sender as a bounce. This is incorrect behavior, because many mail clients will include address of the Sender header in a reply-to-all function, causing Mailman to treat the reply as a bounce. So, in summary, the disadvantages of Mailman's behavior of rewriting the Sender header is that doing so is not in the intended spirit of RFC2822, causes subscription grief, and breaks Outlook. The advantage is that it helps Mailman detect bounces from a slim minority of brain-dead MTAs that send bounces to the Sender header. The problem is that you said you wanted to implement an option to allow people to turn it off, not to rip this feature completely out of the system. I would argue that the best course of action is to excise Sender header rewriting entirely and provide no option to turn it on. (Mailman has way too many options already.) If, however, an option is created to control the behavior, it should definitely default to OFF (no Sender header rewriting), not on. -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
Dallas Bethune wrote: For our uses just changing that list-bounces address to something less ominous looking would help. It definitely looks to me as if something needs to be done. I think perhaps offering 3 options either to the list admin on a per-list basis with a site default or just a site option. I lean towards per-list although it's more work to add to the GUI. The options I see are 1) current behavior with perhaps the addition of putting the original Sender: in another header. 2) like 1) only use list address instead of list-bounces. 3) don't touch Sender: at all. -- 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://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] permissions error with 'make install'
Christopher Adams wrote: I am doing the install as a member of the Mailman group. I have made sure that the installation directory can be written to by that group. I have run 'configure' and 'make' successfullly. When I run 'make install', I get the following: [EMAIL PROTECTED] mailman-2.1.8]$ make install Creating architecture independent directories... chmod o-r /usr/local/mailman/archives/private chmod: changing permissions of `/usr/local/mailman/archives/private': Operation not permitted make: *** [doinstall] Error 1 So, assuming that the problem was changing the permissions for the archives/private directory, I made the change as root and then went back to do the 'make install'. I get the same message, even though I manually had changed the permissions. That chmod is done unconditionally whether or not it is required. For whatever reason, the user running make install does not have permission to do the chmod on the /usr/local/mailman/archives/private directory. You have a few choices to finish the install: - run make install as root or as some user that does have permission to do the chmod. - maybe chown /usr/local/mailman/archives/private to the user who's running make install or figure out why the installing user doesn't have permission and correct that. - remove the line chmod o-r $(DESTDIR)$(var_prefix)/archives/private from the doinstall section of Makefile in the unpack directory If I run check_perms, I get this: [EMAIL PROTECTED] bin]# ./check_perms Warning: Private archive directory is other-executable (o+x). This could allow other users on your system to read private archives. If you're on a shared multiuser system, you should consult the installation manual on how to fix this. No problems found Don't worry about this one. check_perms probably shouldn't report it. It's not really possible to have public archives at all within the present Mailman framework without having the archives/private directory be searchable by the web browser. See the thread that starts at http://mail.python.org/pipermail/mailman-users/2006-April/050591.html for more on this. -- 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://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
Now that I have a few minutes to breath ;) I'll try to summarize my thoughts on this, and then perhaps go back later and follow up to specific points later in the thread. I'm sympathetic to ripping out the Sender: field munging. It was always primarily a workaround for buggy MTAs. If the majority of MTAs out there now Do The Right Thing, then of course we want to be RFC compliant. Outlook's behavior has always been a wart but so far, the benefits have outweighed the costs. If the benefits are minimal now, then it should go. The question that must be answered is: if we no longer munge Sender: header, what are the right headers to set to increase the likelihood that bounces will go where we want them to? I don't care about the minority of still-deployed buggy MTAs that may send bounces to the wrong place as long as we can be reasonably assured they won't send them to /some/ wrong places. For example, I think it would be bad if they started spamming list owners with bounces, very bad if they spammed the original message authors, and worse if they spammed the mailing list with bounces. We have almost none of that now and if we removed the Sender: header and saw a huge increase in this bad behavior, then the benefits of munging the header go way up. Of course, we might not know until we start deploying, which would be too late. I encourage those of you who want to get rid of Sender: munging to modify your Mailman 2.1 code now and see what happens. :) Of course, you'll let us know how that goes! My recommendation would be to record the results in the wiki. I agree that the RFCs are a bit murky in this area, but it's relatively clear that the RFC 2822 'secretary' example illustrates the intent of Sender:. Our list owners are not the agents transmitting the messages, so listname-owner should clearly not go in Sender:. We really want to increase the chances that Mailman will process all bounces. As I mention above, we absolutely can't be a vector for spamming people with bounces they can't do anything about. If some buggy MTAs throw bounces away though, tough luck for their users. There should be enough compliant MTAs out there that the added cost of keeping bogus addresses on a list because we never saw their bounces should be low. I don't really like list or site options for this kind of thing. For one thing, we already have too many options and adding list options complicates the U/I and cognitive load for list admins who usually really don't want to be bothered with this nonsense. We should be reducing the options a list admin has to worry about, not increasing them. This is not really appropriate for a site admin either because that's too coarse of a decision. A Mailman site talks to a huge array of MTAs and MUAs, so I don't think you could make a good choice. If anything, should we determine that Sender: munging has to stay, it should be a user option because only the user knows whether their MUA will present them with an ugly message display. A user could decide to turn off Sender: munging, but I suspect it's still more than the typical user will want to deal with. And of course per-user options get into all the personalization vs. performance issues. Is listname-bounces confusing? Yes, and I wouldn't be opposed to changing this, although I'm not sure what we'd use. listname-processor? Well, let's hope we can just get rid of Sender: munging instead. -Barry signature.asc Description: This is a digitally signed message part -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
On Fri, 2006-04-28 at 13:05 -0500, Neal Groothuis wrote: As I noted in my previous response, I believe that the correct field (if Mailman were to add a Sender: header) to add would be Resent-Sender. Please see RFC 2822, section 3.6.6. Whatever else we decide, I don't agree, or at least, it won't help us. $3.6.6 says that Resent-* headers are to be added by a user. It also says that these are purely informational headers, so I don't see how adding them will instruct a receiving MTA usefully. -Barry signature.asc Description: This is a digitally signed message part -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
On Fri, 2006-04-28 at 14:08 -0400, Bob [EMAIL PROTECTED] wrote: ...Trouble similar to a current problem I am having with AOL: they are bouncing all email with the FROM: address of a specific AOL user, when mailman delivers the messages to -any- aol or cs.com address. Have you tried turning on full personalization so that every recipient gets their own copy? -Barry signature.asc Description: This is a digitally signed message part -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
At 7:50 PM -0400 2006-04-28, Barry Warsaw wrote: On Fri, 2006-04-28 at 13:05 -0500, Neal Groothuis wrote: As I noted in my previous response, I believe that the correct field (if Mailman were to add a Sender: header) to add would be Resent-Sender. Please see RFC 2822, section 3.6.6. Whatever else we decide, I don't agree, or at least, it won't help us. $3.6.6 says that Resent-* headers are to be added by a user. It also says that these are purely informational headers, so I don't see how adding them will instruct a receiving MTA usefully. Siunce the RFC doesn't specifically talk about relay agents as separate from users, I think we could argue that Mailman would qualify as a user in this context. Therefore, the Resent-* headers seem to be most appropriate. But you are correct that these are purely informational and will be completely ignored by any MTA. If we need something that will be noticed by other MTAs beyond the envelope sender and the Return-Path: Errors-To: headers, then we're going to have to carefully think about this. I am still opposed to blindly making this change and letting the community find out what happens. I think we need to gather a lot more information about the likely outcome from this change, and I think the best way to achieve this is through giving admins (either site admins or list admins) the ability to set an option and choose whether or not they want to see what happens. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] Missing Unsubscription Requests
I am hosting a list (running on 2.1.7) that is missing unsubscription requests on the 'admindb' page. The list is configured to have moderated unsubscription requests, so people don't have to confirm their unsubscriptions, which seems to cause a lot of problems. I know the unsubscription request was made because: a) they show up in the 'vette' log b) Some people are sending angry emails to the return address of the list. But those people are still on the list, the list admin (who I know personally) has told me they haven't discarded them, and the unsubscription requests don't show up on the 'admindb' page. I don't mean that all unsubscription requests don't show up, some do. I've looked over the error logs, which do have some errors, but nothing related to unsubscription requests. Any help in debugging this? -- Edward Muller Interlix, LLC -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Missing Unsubscription Requests
Edward Muller wrote: I know the unsubscription request was made because: a) they show up in the 'vette' log b) Some people are sending angry emails to the return address of the list. a) is good evidence. As far as b) is concerned, can people who can't deal with an unsubscribe confirmation be trusted in this ?-) But those people are still on the list, the list admin (who I know personally) has told me they haven't discarded them, and the unsubscription requests don't show up on the 'admindb' page. I don't mean that all unsubscription requests don't show up, some do. Is admin_immed_notify on and if so, does the admin get notice of the missing unsub requests? I've looked over the error logs, which do have some errors, but nothing related to unsubscription requests. Are you absolutely certain the logged errors aren't related? What are they? -- 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://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
