Re: [Mailman-Users] Goodmail spells doom for mailing lists?
Dave == Dave Crocker [EMAIL PROTECTED] writes: You understand that and I understand that, but I don't think it's easy to grasp from the pages whose URLs you posted. What _is_ easy to grasp is that bulk emailers who have been getting a certain level of QoS for free are now being asked to pay for it, and they're upset. Stinks of special interest to high heaven. Dave Let me see if I understand the model: Dave AOL creates a specialized, rather expensive process that it Dave provides for free, to ensure delivery of a class of mail. [If you want to know why Brad asks if you're an intentional shill for the advertising industry, there you have it. The purpose of the process from the point of view of the AOL subscriber is to ensure _non_-delivery of a class of mail. I doubt most subscribers really care whether they get their opt-in mailings from specially selected advertisers---but those advertisers care, and care enough to pay! Most public-service MLs, on the other hand, will not be able to pay. Except those which are mailing solicitations for donations! Who is being served here? Advertisers, not AOL or mailing list subscribers.] Dave The operation of this mechanism is pure overhead for AOL. True, but only because they don't dare charge their subscribers for it. Dave Worse, it is distinct to AOL. To the extent any other Dave receive-side ISP operates such a service, it is entirely Dave independent of AOL. That is, anyone wanting on these special Dave lists must to special things for each of these lists. Dave So along comes a few companies who are trying to find ways Dave to let receive-side ISPs outsource the job of assuring that Dave trustable bulk mail is, in fact, trusted. (That is, the Dave receiver wants this stuff and these services are provding Dave ways to assure that they get it.) Note: trusted _by the ISP_. The ISP should be a reliable representative of their subscribers, or the whole scheme is suspicious. As a former AOL subscriber, I'm pretty sure that AOL never had anything in mind but hanging on to the direct debit for as long as possible. Dave These companies offer mechanisms that will work across Dave multiple receive-side services and they all all charge the Dave sender for the special handling that is needed to bypass Dave most or all of the receive-side filters. (Just to nit-pick, Dave EWL membership does not bypass all filters, while a Goodmail Dave token will, as I understand it.) If a Goodmail token bypasses any user-defined filters, that's spam. If AOL doesn't provide a way for users to define such filters, they're aiding and abetting, no? Ie, they will help the advertiser/Goodmail to push things as close as possible to what the subscriber(s) consider unacceptable. In particular, they are likely to adopt a voting criterion for unwanted, or a wanted until specifically refused criterion. All in the name of maximizing information flow. Dave So one of these services lands some strategic relationships [Ie, attempts to restrict trade. :-) That's all that strategic relationship means, has ever meant, or can ever mean. If it meant something else, you'd call it by a more precise name: customer- supplier, competitor, etc.] Dave and makes a splash announcing them. Somehow, this Dave value-added service is heralded as subversive, Tut, tut. I certainly wouldn't call this service revolutionary, although I wouldn't be surprised if AOL/Goodmail do! Dave in spite of the fact that pretty much all other Dave communication services have levels of service. Dave I must be missing something, here. Yes. First, you may have missed the fact that special interest above refers to bulk emailers who have been getting best QoS for free. Second, the key point is that, up until spam, where carriers provide QoS to third parties, the cost to the third party of getting high quality far exceeded the cost to the user of not picking up the phone. Modern telecommunications, and especially the Internet, changes that comparison; we can no longer assume the costs of ignoring unwanted communication are negligible, and anything that guarantees arrival of a transmission has the potential to impose such costs. Third, the fact that AOL/Goodmail are certifying mail in bulk as an exclusive relationship[1] rather than competitively offering various ways to help users filter at the mailbox level means that they are (more or less deliberately) setting up a situation where they can turn the communication connection to a very large block of users in one click of a GUI. Stretching the point to make a point, under the Sherman Act that's prima facie an illegal combination in restraint of trade.[2] Put it this way: what is wrong with a competitive solution where AOL allows the _users_ to choose _one or more_ filtering service(s)? Besides reducing revenue to Goodmail and AOL (and
Re: [Mailman-Users] Mailman stopped passing messages and new listsdon't appear
Andrew Steele wrote: All was well last Friday, but by today, Monday, I find the following symptoms: 1. No messages sent to any list are distributed. 2. New lists can be created from within the linux shell and appear to be correctly configured. Can you access their listinfo and admin pages directly? 3. New lists created in the shell do not appear in the admin or listinfo pages in a web browser. Are the lists 'advertised'? If so, and if their web pages can be accessed directly, this is probably a virtual hosts issue. I.e., the host portion of the list's web_page_url attribute doesn't match the host portion of the URL you are using to access the admin or listinfo overview pages. Since was well previously I'm considering that the problem has arisen as a result of difficulties at our ISP. However, they are proving unresponsive at this point so I'm wondering if anyone can suggest a course of action to diagnose the problem and then apply whatever solution necessary. Are these lists hosted at the ISP? Can you see Mailman's logs? Can you do 'ps' to see if the qrunners are running? -- 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] Goodmail spells doom for mailing lists?
Stephen, Dave AOL creates a specialized, rather expensive process that it Dave provides for free, to ensure delivery of a class of mail. [If you want to know why Brad asks if you're an intentional shill for the advertising industry, there you have it. The purpose of the process from the point of view of the AOL subscriber is to ensure _non_-delivery of a class of mail. Do you expect your postal service to screen your mail, or your phone company to screen your calls? In other words, this demand that we place on the receive-side email service is really quite extraordinary. That does not make it unreasonable, but it does mean we need to be careful about what we expect and how it is valued (and paid for.) Given the arms-race nature of the filtering world, the cost of doing it well increases without bound. That's not such a good business model, when it represents pure overhead, rather than resulting in direct revenue. (I am assuming that serious discussion about these issues views it as acceptable for a business to make a profit.) lecture More generally, a serious challenge in these kinds of discussions is the failure to see it as requiring a 'negotiation' among the participants, including authors, recipients, and all the operators. Each has different goals and constraints, and some of the constraints compete with each other. So we need to approach the topic with an understanding that there are no perfect solutions. Equally, every set of participants has some good actors and some bad actors. Not everyone who sends bulk mail is doing a bad thing. Not everyone who complains about mail they receive is doing so carefully and in good faith. So this negotiation towards an acceptable-but-imperfect solution must worry about misbehaviors from any direction. And the third challenge is that this all involves a bit of very large-scale, very important infrastructure operation. No one -- and I mean no one -- knows how to do that perfectly. The absolute rule when making any change to a social system -- and email definitely is one -- is that will have unintended consequences, most of which will be undesirable. /lecture What we have today is an undifferentiated mass of email, with a very poor signal to noise ratio. What the services that focus on good reputation are trying to do is to identify a class of senders who will have a very *good* signal to noise ratio, and thereby handle this safer set of mail in a way that gives better service, namely better delivery assurances. Once we agree that this is a reasonable goal, then we are debating methodology. My own view is that any new methodology for a difficult problem is an experiment. Some experiments look more plausible than others, but ultimately, none of them has a certain outcome. The only thing that is important is to make sure that it is possible to conduct multiple experiments and that the evaluation of them can be done by the market. The hyperbole and polarization, present in the current public environment, makes sure that serious market evaluation is not possible. I doubt most subscribers really care whether they get their opt-in mailings from specially selected advertisers---but those advertisers care, and care enough to pay! This represents a good example of missing the point. The better signal-to-noise efforts are not focusing on delivering advertising but on servicing existing customer relationships. The pristine example of this is transaction mail -- and that has nothing to do with advertising. Of course, companies with whom one does transactions also tend to send advertising, but there is a world of difference between getting that sort of bulk mail -- that I might not want -- from getting the masses of fraudulent and deceptive mail from people with whom I have no relationship at all. At least when it is a company with which I have a history, there is a reasonable chance of fixing the problem. Hence, debates about how it gets fixed are a matter of quibbling, in comparison to the larger and strategic issues of controlling spam from the really bad actors. Most public-service MLs, on the other hand, will not be able to pay. There are two different lines of response to this: 1. Of course we all want to be nicer to organizations that have an altruistic quality about them. Unfortunately, we need to be careful about defining this special class and defining their special benefits, lest we wind up giving benefits to people and activities that are not really altruistic. 2. These altruistic activities pay for other utilities just like the rest of us. Why must they be given special pricing (e.g., free service) in this case? These are competing points. So, once again, we are faced with inherent difficulty in any effort to resolve them. Again, it might give one a nicely warm feeling to claim that things are much simpler than I am describing and that they is easy to resolve,
Re: [Mailman-Users] show_qfiles error
Hi! I know, this reply comes about one year too late ;-) but nevertheless, here's the solution (and a bug report): When I try to view the qfiles in my in out or retry directories I get an error like the following: /usr/local/mailman/bin/show_qfiles qfiles/in/*.pck qfiles/in/1109557589.84778+7a750d59fd76a54b51168a615ef23e74f4088be9.pck Traceback (most recent call last): File /usr/local/mailman/bin/show_qfiles, line 74, in ? main() File /usr/local/mailman/bin/show_qfiles, line 67, in main sys.stdout.write(msg.as_string()) AttributeError: 'str' object has no attribute 'as_string' Edit show_qfiles, remove the .as_string() after msg just leaving the line sys.stdout.write(msg) Patch: --- show_qfiles-2.1.7.orig 2006-03-06 22:38:46.0 +0100 +++ show_qfiles-2.1.7 2006-03-06 22:40:27.0 +0100 @@ -64,7 +64,7 @@ fp = open(filename) if filename.endswith(.pck): msg = load(fp) -sys.stdout.write(msg.as_string()) +sys.stdout.write(msg) else: sys.stdout.write(fp.read()) This bug is still in Mailman 2.1.7. I initially had this problem with Mailman 2.1.5 on SuSE Linux 9.3 with Python 2.4, but also could reproduce it with 2.1.7 on SuSE Linux 10.0 with Python 2.4.1. Filed a bug report: https://sourceforge.net/tracker/?func=detailaid=147group_id=103atid=100103 Anyone can explain, why a string should be converted to a string? Kind regards, Axel Beckert -- - Axel Beckert ecos electronic communication services gmbh it security solutions * web applications with apache and perl Mail: Tulpenstrasse 5 D-55276 Dienheim near Mainz E-Mail: [EMAIL PROTECTED] Voice: +49 6133 939-220 WWW:http://www.ecos.de/ Fax: +49 6133 939-333 - ** Virus checked by BB-5000 Mailfilter ** -- 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] Spam assassin with mailman
The issue we're having is that Mail comes in through our mail server. Shoots to Mailman. Mailman then finds the list, sends the mail back to the mail server and only then does the mail get hit by spam assassin. If the email was sent as a blacklisted spam, once it hits mailman it doesn't appear that way to spam assassin anymore because it is seeing it come from mailman and things it's okay thus sending it out. Does anyone have any suggestions on how to correct this problem? I showed my systems admin the spam assassin integration into mailman instructions but he's hesitant on it because the instructions I found haven't been touched since 2003. im only human so maybe I didn't find the most recent instructions. Any and all help is appreciated. Thanks guys/gals If i was a rabbit, i would ROLL... ROLL! -Kompressor Jonathan Larsen The Awesome I.S. Dept Questions? mail us mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Call us 801.257.5754 Fax us 801.366.5702 -- 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] show_qfiles error
Axel Beckert - ecos gmbh wrote:
When I try to view the qfiles in my in out or retry directories I get an
error like the following:
/usr/local/mailman/bin/show_qfiles qfiles/in/*.pck
qfiles/in/1109557589.84778+7a750d59fd76a54b51168a615ef23e74f4088be9.pck
Traceback (most recent call last):
File /usr/local/mailman/bin/show_qfiles, line 74, in ?
main()
File /usr/local/mailman/bin/show_qfiles, line 67, in main
sys.stdout.write(msg.as_string())
AttributeError: 'str' object has no attribute 'as_string'
Edit show_qfiles, remove the .as_string() after msg just leaving
the line
sys.stdout.write(msg)
snip
This bug is still in Mailman 2.1.7. I initially had this problem with
Mailman 2.1.5 on SuSE Linux 9.3 with Python 2.4, but also could
reproduce it with 2.1.7 on SuSE Linux 10.0 with Python 2.4.1.
Filed a bug report:
https://sourceforge.net/tracker/?func=detailaid=147group_id=103atid=100103
Anyone can explain, why a string should be converted to a string?
It's more complicated than that. I don't know why you had a problem
originally with the out or retry queues, and I suspect that your
patched show_qfiles may have problems with them.
The issue, is that in the entry in the in queue, the msg is usually the
text of the incoming email, but elsewhere, the msg is a
Mailman.Message.Message object.
So, yes msg.as_string() is usually wrong for entries from the in queue,
but not elsewhere. I think a more appropriate patch is something like
@@ -64,7 +64,11 @@
fp = open(filename)
if filename.endswith(.pck):
msg = load(fp)
-sys.stdout.write(msg.as_string())
+data = load(fp)
+if data.get('_parsemsg'):
+sys.stdout.write(msg)
+else:
+sys.stdout.write(msg.as_string())
else:
sys.stdout.write(fp.read())
--
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] Spam assassin with mailman
Jonathan Larsen wrote: The issue we're having is that Mail comes in through our mail server. Shoots to Mailman. Mailman then finds the list, sends the mail back to the mail server and only then does the mail get hit by spam assassin. If the email was sent as a blacklisted spam, once it hits mailman it doesn't appear that way to spam assassin anymore because it is seeing it come from mailman and things it's okay thus sending it out. Does anyone have any suggestions on how to correct this problem? I showed my systems admin the spam assassin integration into mailman instructions but he's hesitant on it because the instructions I found haven't been touched since 2003. im only human so maybe I didn't find the most recent instructions. http://www.jamesh.id.au/articles/mailman-spamassassin/ Yes, it's old, but works just fine with current SA and MailMan. I use it on ALL my sites, including some high profile ones. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -- 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] Spam assassin with mailman
Jonathan Larsen wrote: The issue we're having is that Mail comes in through our mail server. Shoots to Mailman. Mailman then finds the list, sends the mail back to the mail server and only then does the mail get hit by spam assassin. Why is your MTA doing spam detection on outgoing mail and not on incoming mail? This seems exactly backwards to me. -- 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] Spam assassin with mailman
Besides the integration. Is there another way to solve this problem? -Original Message- From: Larry Rosenman [mailto:[EMAIL PROTECTED] Sent: Monday, March 06, 2006 3:54 PM To: 'Jonathan Larsen'; mailman-users@python.org Subject: RE: [Mailman-Users] Spam assassin with mailman Jonathan Larsen wrote: The issue we're having is that Mail comes in through our mail server. Shoots to Mailman. Mailman then finds the list, sends the mail back to the mail server and only then does the mail get hit by spam assassin. If the email was sent as a blacklisted spam, once it hits mailman it doesn't appear that way to spam assassin anymore because it is seeing it come from mailman and things it's okay thus sending it out. Does anyone have any suggestions on how to correct this problem? I showed my systems admin the spam assassin integration into mailman instructions but he's hesitant on it because the instructions I found haven't been touched since 2003. im only human so maybe I didn't find the most recent instructions. http://www.jamesh.id.au/articles/mailman-spamassassin/ Yes, it's old, but works just fine with current SA and MailMan. I use it on ALL my sites, including some high profile ones. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -- 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] Spam assassin with mailman
Jonathan Larsen wrote: Besides the integration. Is there another way to solve this problem? SpamAssassin scan the incoming mail before Mailman gets it's grubby paws on it. I actually do both. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -- 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] Spam assassin with mailman
At 3:57 PM -0700 2006-03-06, Jonathan Larsen wrote: Besides the integration. Is there another way to solve this problem? Integrate it into the MTA. See FAQ 6.12 for one example. -- 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] Integrating Namazu with Mailman
Hello, I am trying to integrate the namazu search with mailman archives. I am able to get namzu list out the messages containg the search string. But, when I click on the message, it just come back with the error: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request. On checking the apache/error_log, I see the following message that has some (8)Exec format error: [Mon Mar 06 16:40:09 2006] [error] [client 143.103.41.10] File does not exist: /disk1/mailman/favicon.ico [Mon Mar 06 16:40:10 2006] [error] [client 143.103.41.10] (8)Exec format error: exec of '/disk1/mailman/cgi-bin/archives/private/sysadmin/2006-January/000161.html' failed, referer: http://utc80/mailman/Sysadmin/namazu.cgi?query=jamessubmit=Search%21max=20result=normalsort=score [Mon Mar 06 16:40:10 2006] [error] [client 143.103.41.10] Premature end of script headers: 000161.html, referer: http://utc80/mailman/Sysadmin/namazu.cgi?query=jamessubmit=Search%21max=20result=normalsort=score [Mon Mar 06 16:40:11 2006] [error] [client 143.103.41.10] File does not exist: /disk1/mailman/favicon.ico Has anyone successfully accomplised mailman+namazu+apache integration? BTW, I went with the referernce document at : http://mail.python.org/pipermail/mailman-users/2004-June/037580.html Any help will be appreciated. Thanks Elvis Fernandes * *** -- 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] Redirect all -bounce emails
Hi Mark, My best guess here is that [EMAIL PROTECTED] is a member of the [EMAIL PROTECTED] list. Yes, that was correct. And hence the mails were getting into a bounce loop. I have removed [EMAIL PROTECTED] from [EMAIL PROTECTED] I was s stupid to do it in the first place, but this was a great learning for me. All is good now. Thanks Tom On 2/23/06, Mark Sapiro [EMAIL PROTECTED] wrote: Tom Kavanaugh wrote: I modified the Mailman/Handlers/SMTPDirect.py per you suggestions. The unix_sysadmin-bounce emails now get redirected to [EMAIL PROTECTED] That is the good part. But what is happening now is that the mailman server keeps spitting out these emails to the mailman mail list. Every few minutes I am bomarded with these emails from the mailman mail list. The relevant contents are: You asked how to redirect bounces to the [EMAIL PROTECTED] address (the posting address for the site list) and that's what's happening. Reporting-MTA: dns; utc80.name.com Received-From-MTA: DNS; localhost Arrival-Date: Thu, 23 Feb 2006 16:13:39 -0800 (PST) Final-Recipient: RFC822; [EMAIL PROTECTED] [EMAIL PROTECTED] Action: failed Status: 5.1.1 Remote-MTA: DNS; mailhost.name.com Diagnostic-Code: SMTP; 550 5.1.1 [EMAIL PROTECTED] [EMAIL PROTECTED]... User =09unknown Last-Attempt-Date: Thu, 23 Feb 2006 16:13:39 -0800 (PST) Seems that the mailman server (utc80) is re-trying to send to [EMAIL PROTECTED], although it knows that this is an unknown user. Mailman doesn't know anything about what addresses are or are not deliverable, and since you have effectively disabled automatic bounce processing, it can never find out. My best guess here is that [EMAIL PROTECTED] is a member of the [EMAIL PROTECTED] list. If that's not it, I don't know what is. Does that notice contain a copy of the original message? if so, what is it? Or does it keep growing as the same bounce keeps rebouncing? This is an interesting issue. Every message from the [EMAIL PROTECTED] list had better be deliverable or you will get a bounce loop. -- 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] Spam assassin with mailman
It does do it on incoming mail but only after it's went to mailman and then is going back to the MTA for final delivery. So basically right before it hits the user. -Original Message- From: Mark Sapiro [mailto:[EMAIL PROTECTED] Sent: Monday, March 06, 2006 3:56 PM To: Jonathan Larsen; mailman-users@python.org Subject: Re: [Mailman-Users] Spam assassin with mailman Jonathan Larsen wrote: The issue we're having is that Mail comes in through our mail server. Shoots to Mailman. Mailman then finds the list, sends the mail back to the mail server and only then does the mail get hit by spam assassin. Why is your MTA doing spam detection on outgoing mail and not on incoming mail? This seems exactly backwards to me. -- 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] Spam assassin with mailman
Jonathan Larsen wrote: It does do it on incoming mail but only after it's went to mailman and then is going back to the MTA for final delivery. So basically right before it hits the user. I don't want to argue the semantics with you, but whatever you want to call it, the MTA should be applying the it's spam filtering before the mail is given 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://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] Posting with sending ID concealed
I operate a mailing list to issues updates and information to my patients. The list is fully moderated, disallowing anyone to post without review. Occasionally, I get some patients who respond back to something I send, and I want to post their response, but I'd like to have it post with the identity of the original poster concealed. Is this possible? Dr. Jones -- 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] Posting with sending ID concealed
Dr. Scott S. Jones wrote: I operate a mailing list to issues updates and information to my patients. The list is fully moderated, disallowing anyone to post without review. Occasionally, I get some patients who respond back to something I send, and I want to post their response, but I'd like to have it post with the identity of the original poster concealed. Is this possible? There are at least two ways to do this. If you make the list anonymous, (anonymous_list = Yes on the General Options page) you can approve the post (assuming it was held for approval) and information identifying the user in message headers will be removed, and the From: will be from the list and not the user. This won't remove any identifying material such as a signature from the body of the message however. Alternatively, you can just forward the reply back to the list, editing it as necessary to remove any identifying information. This may be preferable for other reasons as you can also add your own note as to why you think the information in the reply is of interest and remove anything that might not be relevant. -- 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] Spam assassin with mailman
At 5:58 PM -0700 2006-03-06, Jonathan Larsen wrote: It does do it on incoming mail but only after it's went to mailman and then is going back to the MTA for final delivery. So basically right before it hits the user. Which is absolutely bass-ackwards. Do the check in the MTA before you receive the message the first time, then configure a second MTA where you can dump stuff for outgoing traffic which doesn't waste your time by re-doing the same check all over again. -- 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] Integrating Namazu with Mailman
Elvis Fernandes wrote: On checking the apache/error_log, I see the following message that has some (8)Exec format error: [Mon Mar 06 16:40:09 2006] [error] [client 143.103.41.10] File does not exist: /disk1/mailman/favicon.ico Above is not a problem. [Mon Mar 06 16:40:10 2006] [error] [client 143.103.41.10] (8)Exec format error: exec of '/disk1/mailman/cgi-bin/archives/private/sysadmin/2006-January/000161.html' failed, referer: http://utc80/mailman/Sysadmin/namazu.cgi?query=jamessubmit=Search%21max=20result=normalsort=score This is definitely a problem. It appears that the namazu.cgi script is trying to redirect the query to something like http://utc80/mailman/archives/private/sysadmin/2006-January/000161.html which should really be http://utc80/mailman/private/sysadmin/2006-January/000161.html - it looks like you may have configured a path where you should have configured a URL. [Mon Mar 06 16:40:10 2006] [error] [client 143.103.41.10] Premature end of script headers: 000161.html, referer: http://utc80/mailman/Sysadmin/namazu.cgi?query=jamessubmit=Search%21max=20result=normalsort=score This is probably a consequence of the above error. -- 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
