Mailman 3 August 2006 - Mailman-Developers

Re: [Mailman-Developers] Fwd: suggested improvement for Mailman's bounce pro
by gail.trac＠verizon.net 15 Aug '06

15 Aug '06

>I can certainly see why many people would get to the point where they >start feeling like e-mail no longer has any real value. I certainly >feel that way about most USENET newsgroups I know of, and for the >same reasons. >Brad Knowles, <brad(a)stop.mail-abuse.org> Eamil has indeed become very frustrating lately, my email client is currently fried and hopefully the guy coming over tonight can figure out how to retrieve it, i've tried all i know and can't get it to open at all. I also get all the spam you've talked about, and the current software we're using to host a list on sends me every piece of spam received for any imaginary address the spam folks make for the domain on top of my more than healthy dose of personal spam of course. Its very annoying and at times its been a good thing I can't quite reach the computer to throw it out into oncoming traffic, however, I work at home so its a vital part of what allows me to do the various jobs from home. Now, I've noticed a marked decrease in the viruses circulating in recent months, and a huge increase in spam at about the same time. A very senior tech guy I respect a great deal has told me that the virus writing jerks have now been hired to write software that spreads spam like they used to spread viruses and I believe it. I told him i was getting the same sort of sinking feeling about the internet hanging on by a thread like i used to get when the major finanacial services applications i worked with were about to crash and he brought that up in response. I used to say, about the virus jerks, that if only they'd put their talents to some good use they could change or rule the world and make a fortune doing it, unfortunately it appears they've now figured out how to make that fortune doing spam instead of something 'good' for the world. Sad isn't it? Gail

1 0

Re: [Mailman-Developers] Fwd: suggested improvement for Mailman's bounce processing
by Ian Eiloart 15 Aug '06

15 Aug '06

I'm taking this back on list, since I think the principles are relevant to Mailman. --On 10 August 2006 17:07:48 -0700 Jeff Schnitzer <jeff(a)infohazard.org> wrote: > Ah, you want to reject /senders/ at SMTP time, not recipients. Ignore my > last message. > > There's no reason why SubEtha can't bounce mail from unknown senders. It > would not be difficult to do*, and may show up in a future release. > However, it's not the universally appropriate solution. Yes, I know. I filed a bug report, and was told it was a feature not a problem. That's when I stopped considering using the s/w. This was a couple of months ago. If the situation changes, then it would be worth considering again. > I see three > different solutions to this problem (mail from unknown recipients): > > 1) Reject it at SMTP time. Legitimate senders are notified that their > mail was not delivered but there is no opportunity to auto-moderate the > message or any opportunity for list administrator to moderate the > message. Great for spam rejection though. > > 2) Hold the message and send the envelope sender instructions to > auto-moderate. Very friendly to legitimate users but bad for the > recipients of joe-jab attacks. However, using SPF makes this a > non-issue. I'm not anti-spf in principle - unlike Brad. However, it's not widely deployed so it can't be relied on in this case. > Using this on a relatively isolated network or behind heavy > spam control makes this a non-issue. Well, there wouldn't be much point putting an MLM server on an isolated network. Not for us, where inter-institutional collaboration is very important. > 3) Hold the message silently, sending no instructions for > auto-moderation. This is not so friendly for legitimately confused users > whose messages go into a vacuum, but the ideal circumstance for > announce-only lists which *always* moderate all messages. Of course, > this is just fine for spam control. Yes, that sucks, but that's where we're left with Mailman. In fact, it's one of the main reasons I'm looking for a MLM that does (1). I can't think of any case in which (3) is better than (1). > There are perfectly legitimate reasons to use any of these 3 approaches. > We started off with #2, and will probably eventually accommodate all > three. I'm sorry if it's not on a schedule that makes you happy, but we > certainly do accept patches. > > * This depends on what sort of MTA you are using. If SubEtha is directly > receiving public input, it's trivial. If inbound mail is being relayed > through another MTA, it gets a lot more complicated. The problem is not > a design issue in SubEtha, it's the antiquated design of all commonly > used MTAs. Anyone who wants to integrate *anything* with > Postfix/Exim/Sendmail/Qmail and friends will be frustrated - they just > don't provide easy hooks into the SMTP exchange. No, it's very easy common to do call forwards with Exim. That would tell me when the list won't accept the sender. So, if Brad's right about Postfix and Sendmail, that just leaves Qmail and friends. Never mind. -- Ian Eiloart IT Services, University of Sussex

5 16

Fwd: suggested improvement for Mailman's bounce
by gail.trac＠verizon.net 14 Aug '06

14 Aug '06

>Today, held messages still have to be approved by the moderator. >What I propose is to allow posters to self-moderate, simply by >verifying that their address is real. This probably means a >clickable link and (maybe) a header cookie for replying. Think >Gmane's auto-moderation approach. >- -Barry I do hope this is meant to be an option the list administrator can set if they want to allow it, not that this would happen for all lists? We're looking to have a totally moderated list, with the moderator's ability to edit certain things out, not change the member's content, but eliminating things like over quoting, and cleaning up format issues too. Will that no longer work? Gail

2 1

Re: [Mailman-Developers] Fwd: suggested improvement for Mailman's bounce processing
by Bob Puff＠NLE 14 Aug '06

14 Aug '06

Jon Scott Stevens wrote: > Since the user doesn't have permission to post to the list, the users > message would just get held in the moderation queue and you could > safely ignore it until the queue is auto deleted after a period of > time. The idea being that if the moderation queue only has spam > (because members are given a chance to self moderate if need be... and > the reason for this discussion), then you pretty much just ignore the > queue entirely. This makes the list admin's job trivial. So, even in > your configuration, you would actually want this auto-moderation feature. > > jon Hi Jon, No, I don't want non-members ever being able to post a message. This did happen by accident to one 5000+ member announce-only list, and all hell broke loose! <g> Bob

1 0

Re: [Mailman-Developers] Fwd: suggested improvement for Mailman's bounce processing
by Bob Puff＠NLE 14 Aug '06

14 Aug '06

Hi Jon, No, I want them to get a message saying they can't do that. The majority of my lists are either one-way announcements or private discussion groups. On the announcement lists, I just drop the messages. They get a lot of spam. Bob Jon Scott Stevens wrote: > On Aug 14, 2006, at 7:27 AM, Bob Puff wrote: > >> This should definitely be configurable, if implemented. I don't have >> any >> lists that would benefit by this... in fact, this is not desirable on >> any of >> my lists. >> >> Bob > > > I'm curious... every time someone sends email to one of your lists from > an address which is not subscribed (ie: their home email or something), > you want to moderate it for them? Wouldn't you rather do less work if > they could self moderate it themselves? > > jon >

1 0

Re: [Mailman-Developers] Fwd: suggested improvement for Mailman's bounce processing
by Ian Eiloart 14 Aug '06

14 Aug '06

--On 11 August 2006 19:38:34 -0700 Jeff Schnitzer <jeff(a)infohazard.org> wrote: > Brad Knowles wrote: >> Okay, now that's different. This actually clicks in very well with >> the recent article I wrote on fighting spam for publication on the >> LOPSA website, because backscatter has become one of my biggest hot >> buttons lately. Putting an intelligent limiter on the potential >> causes of backscatter (like no more than one notice per recipient per >> day, or whatever), brings it down into the realm of what I would >> consider to be less than ideal but at least below the threshold of >> "totally unacceptable". > > Ok, I just checked this 5-minute fix into SubEtha. Happier, Ian? > > Jeff Yes, that's great! I'd guess that this is 90-99% improvement. In fact, I'd probably use that feature for my local domain (sussex.ac.uk), which is virtually spam free because I only accept from that domain if it's been authenticated, or locally submitted, or has a header that was added by our MSA servers. In fact, the only spam I get into my "local" mailbox is Mailman moderation requests. I'd still want to reject at SMTP time for non-local domains, though. -- Ian Eiloart IT Services, University of Sussex

1 0

suggested improvement for Mailman's bounce processing
by James Ralston 10 Aug '06

10 Aug '06

Consider the following situation: 1. Some users at our site are subscribed to external Mailman-managed mailing lists that perform automatic bounce processing. 2. Because the list owners are either unwilling are unable to protect the lists from spam, the lists receive a fair amount of spam. 3. Our MX servers are configured to reject outright incoming messages that are obviously spam. Most of you can see the impending train wreck already, but for completeness' sake, here's the problem: 1. Mailman distributes obvious spam to the list. 2. We detect the spam and reject it during the SMTP dialog with a 550 reply code (5.7.0 extended status code). 3. Mailman receives a DSN message because we bounced the message. 4. Mailman assumes that the bounce is due to the recipient's address being invalid, and disables the subscription. 5. Much wailing and gnashing of teeth ensues. >From looking at Bouncers/DSN.py, although Mailman takes the time to pick apart each message/delivery-status subpart and extract the "action" field, it blissfully ignores the "status" field, which must be present and must contain the extended status code which generated the DSN. The subject sub-code of the extended status code classifies the status as follows: X.0.XXX Other or Undefined Status X.1.XXX Addressing Status X.2.XXX Mailbox Status X.3.XXX Mail System Status X.4.XXX Network and Routing Status X.5.XXX Mail Delivery Protocol Status X.6.XXX Message Content or Media Status X.7.XXX Security or Policy Status Of these, some subject sub-codes (e.g.: X.2.XXX) pertain directly to the validity of the destination address. But some do *not* pertain to the destination address: for example, X.6.XXX clearly means that the *content* of the message (not the source or destination address) caused the DSN. Regardless, Mailman ignores all of the status field information: if the action is "failed", Mailman counts it as a bounce, and that's that. IMHO, this is an error. I propose modifying Bouncers/DSN.py as follows: 1. Mailman tries to extract the status field from message/delivery-status subpart. 2. If Mailman cannot extract the status field, it operates solely on the action field. 2. If Mailman can extract the status field, and the subject sub-code is X.6.XXX or X.7.XXX, Mailman assumes that the DSN was generated by the fluke content of a specific message, and ignores the DSN. I admit that this algorithm isn't perfect. But I think it's better than what Mailman does currently, which is to ignore the status field entirely. Thoughts? Arguments? James

6 30

Re: [Mailman-Developers] The Philosophy of Web Use.
by Laura Carlson 08 Aug '06

08 Aug '06

--On Thursday, August 3, 2006 7:14 PM -0400 emf <i(a)mindlace.net> wrote: > You're a goddess, laura. Thanks so much for the docking-boxes hookup. > > ~ethan You're most welcome, Ethan. It may have some potential to aid usability in some circumstances. Just be careful to heed the warnings and restrictions on its use for application interfaces. Laura ___________________________________________ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN U.S.A. 55812-3009 http://www.d.umn.edu/goto/webdesign/

1 1

Re: [Mailman-Developers] Please confirm your message
by Ian Eiloart 08 Aug '06

08 Aug '06

Bob, This is very annoying. --On 8 August 2006 05:47:01 -0400 Bob Puff <bob(a)nleaudio.com> wrote: > Hello iane(a)sussex.ac.uk, > > ** IMPORTANT! Please Read! ** > In an effort to reduce spam, a message filtering service called TMDA has > been implemented on this mailbox. > > The purpose of this message is to verify that you, a live human, did > indeed sent a message (shown below) to this mailbox. > > It is IMPORTANT that you do one of the following two things: > > > 1. Simply reply to THIS message (you don't need to type anything, just > send a blank message), or > > 2. Click on this link: > http://nleaudio.com/cgi-bin/tmda.cgi?501.1155030421.24086.12f493 > > > After doing so, your messages will go through automatically, and you will > not see this message again. If you do not reply to this email within > three weeks, your original message may be lost. > > Thank you for your patience. This one small step saves this user from a > ton of spam. > -- Ian Eiloart IT Services, University of Sussex

1 0

Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [7965] branches/Release_2_1-maint/mailman
by Barry Warsaw 06 Aug '06

06 Aug '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 4, 2006, at 8:21 AM, tkikuchi(a)users.sourceforge.net wrote: > Revision: 7965 > Author: tkikuchi > Date: 2006-08-04 05:20:33 -0700 (Fri, 04 Aug 2006) > ViewCVS: http://svn.sourceforge.net/mailman/?rev=7965&view=rev > > Log Message: > ----------- > Language files update. New languages: Arabic, Vietnamese. > Hi Tokio! Were you planning on porting these changes to the trunk, or should I? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRNNmx3EjvBPtnXfVAQLwUQP/b/Ratukf5YVM+6gsLQ43unw4pbSFT2xf itLJO2f5OGRRP1slhp6LftXtBW4dGp9rUwlNBS3fTGQ5ervTX/+oQAVowMaVCJ4S wxohYg84ngrQr2NEjXfZZexTO/iS1xmp5d+iHTLseXezdQByTPzhGY0Wdv4LStyn 4I6yQI4y3aw= =G3Kc -----END PGP SIGNATURE-----

2 2