I have a front end for smartlist lists for penpals of my students. They introduce themselves, a list is created for them, and their first messages are piped to flist.
Smartlist however, no doubt because hello messages in the traditional type of list are not welcome, puts messages like the following in the request file, with the X-Diagnostic header, Unprocessed.
From: "alvinhsu99"alvinhsu99@kimo.com.tw Reply-To: "alvinhsu99"alvinhsu99@kimo.com.tw Subject: ^_^......!!! MIME-Version: 1.0 Content-Type: text/plain; charset="Big5" Message-Id: 20010503084935.ITJK22916.n16-svc.kimo.com@k15.svc.kimo.com.tw Date: Thu, 3 May 2001 16:49:35 +0800 X-Diagnostic: Unprocessed X-Envelope-To: lealv Status: RO Content-Length: 442 Lines: 6
hello....... I am 180cm tall and 83 kg......a little bit fat ....right???I was living by +myself in the school but I go home every weekend on friday and go to school on +Sunday.....I like hip hop music too.....also Rap and +blue......^^....alright.....c ya later......
Or, if they are very short, the X-Diagnostic message is, Already on list.
How can I turn this hypersensitivity off. I have 70 lists so doing them all by hand is too much.
At 4:50 AM -0400 5/11/01, Greg Matheson is rumored to have typed:
I have a front end for smartlist lists for penpals of my students. They introduce themselves, a list is created for them, and their first messages are piped to flist.
Depending on the size of these auto-created "lists," I'm betting setting up sendmail aliases would be more efficient. Of course, if you have hundreds of "subscribers" to these lists, I withdraw the comment.
Smartlist however, no doubt because hello messages in the traditional type of list are not welcome, puts messages like the following in the request file, with the X-Diagnostic header, Unprocessed.
Start doubting. It has nothing whatsoever to do with this being a "hello" message (SmartList isn't smart enough to read the message and determine the context; and I don't know why you would assume a "hello" indroduction message would _not_ be welcomed in a "traditional" kind of list - they certainly are in the "traditional" lists _I_ operate!)...it has more to do with goofy subjects and oddly-formed bodies.
The X-Diagnostic: header field you're seeing is coming from rc.request, not rc.submit; therefore the message is being redirected from rc.submit to rc.request in the mistaken belief that it is an administrative request (subscribe, unsubscribe, etc.) - I've seen this happen rarely with goofy messages like this one, with a bunch of punctuation (particularly lines of periods) in the subject field or "key" words in the first line of the body ("join" and the like). Infrequently (in "traditional" lists, which is what SmartList is designed to operate) these goofy lines will fool the regex scores high enough to cause a redirect. Once it's there. of course, rc.request can't make hide nor hair of it, and punts it off to the maintainer with the "No clue, Boss" X-Diagnostic.
It happens rarely enough for me I never bothered going through the programming in rc.submit that checks (easier to fix the broken subjects and request that the poster not do that anymore), but search for:
# # Does it look like a regular submission? # Or perhaps more like an administrative request? # Look at the start of the body, and see if this could be an administrative # request, pass it on to rc.request in that case. #
...in rc.submit; carefully read the recipies that follow, and modify (CAREFULLY!) to taste. (Considering that you seem to be using SmartList for something...unique...you might consider remming out the recipies entirely. Ugly, and will probably cause you other problems down the road, but will fix this one anyway.)
Charlie
At 10:51 -0400 11 May 2001, Charlie Summers charlie@lofcom.com wrote:
[ About the check for requests sent to the submission address ]
something...unique...you might consider remming out the recipies entirely.
No need to do that. SmartList already has a way to turn this off, unsetting $divertcheck in rc.custom. In your rc.custom file there should be a block like:
#divertcheck = yes ##divertcheck # uncomment to disable the check for # misfiled administrative # requests
To adjust it, simply remove the two '#' characters at the beginning of the second line.
Ugly, and will probably cause you other problems down the road, but will fix this one anyway.)
Disabling this shouldn't cause any problems other than that the entire list will get to see subscribe and unsubscribe messages from people who can't figure out the correct place to send them.
At 3:07 PM -0400 5/11/01, Aaron Schrab is rumored to have typed:
No need to do that. SmartList already has a way to turn this off, unsetting $divertcheck in rc.custom.
Er...duh! Thanks for the correction. (Nothing like doing everything the hard way...)
Charlie
On Fri, 11 May 2001, Charlie Summers wrote:
Start doubting. It has nothing whatsoever to do with this being a "hello" message (SmartList isn't smart enough to read the message and determine the context; and I don't know why you would assume a "hello" indroduction message would _not_ be welcomed in a "traditional" kind of list - they certainly are in the "traditional" lists _I_ operate!)...it has more to do with goofy subjects and oddly-formed bodies.
Sorry, I must have confused 'hello' with 'gimme'. Grepping through .etc and .bin directories, I can't find 'hello'.
The X-Diagnostic: header field you're seeing is coming from rc.request, not rc.submit; therefore the message is being redirected from rc.submit to rc.request in the mistaken belief that it is an administrative request (subscribe, unsubscribe, etc.)
The relevant section of rc.submit is:
# Does it look like a regular submission? # Or perhaps more like an administrative request? # Look at the start of the body, and see if this could be # an administrative request, pass it on to rc.request in # that case. #
:0 * $$=^0 * 9876543210^0 !divertcheck ?? y { }
This section probably gives a high score if divertcheck is set (or is that not set?).
:0 * $$=^0 * !B ?? ^^(.*$(.*$(.*$(.*$(.*$(.*$(.*$(.*$)?)?)?)?)?)?)?)?[^]>} a-z0-9] * 9876543210^0 B ?? ^^.*$.*$.*$.*$.*$.*$.*$.*$.*$ { }
The first condition carry overs the score from the previous recipe. The second matches if the body isn't of the form ^^(.*$(.*$(.*$(.*$(.*$(.*$(.*$(.*$)?)?)?)?)?)?)?)?[^]>} a-z0-9] I'm betting that means if there are no alphanumeric characters in the first 10 lines. The last condition adds a high score if the body is at least 9 lines in length, I think.
I think I'll try taking a few of those .*$ out in the third condition and see what happens.
Greg Matheson lang-sl@ms.chinmin.edu.tw wroteP:
I think I'll try taking a few of those .*$ out in the third condition and see what happens.
I'm not sure whether this will answer your question or not (since I'm not 100% clear what your specific question was), but if I understand correctly, you are thinking that Smartlist doesn't want to put short "hello" messages through to your list. Is this right?
It's not the shortness of a message [alone] that causes the "unprocessed" problem. Super-short messages will be unprocessed if 1) they have no subject, or 2) they have only non-alphabetic characters -- such as "!!!" or ";)" -- in the subject. (I've never been bugged enough to try to figure out WHY these things make Smartlist so unhappy -- I just know that they do.)
I keep a pre-written message handy to send out to individuals when this happens on my lists telling them that the list program thinks very short messages are people needing help and it sends them to me to process; then I tell them if they will simply add a subject (or use actual letters in their subject) and resend, it should go through. They then add a subject and resend and their message does go through. (Which is how I know it's not the shortness alone that matters, but the shortness and subject combined. It took me many months of saving and comparing unprocessed postings before I was able to notice the pattern they all had in common.)
Since the example you posted here had the subject "^_^......!!!" that's what the problem is in this case. If that message were given a "normal" subject, Smartlist should put it through.
Violet xoxox
At 7:55 AM -0400 5/16/01, Greg Matheson is rumored to have typed:
Sorry, I must have confused 'hello' with 'gimme'.
He, he...I think we all have list subscribers who do the same thing, eh? ;)
I think I'll try taking a few of those .*$ out in the third condition and see what happens.
As Aaron already mentioned when gently correcting my earlier post, all you need to do is unset $divertcheck in your rc.custom to solve your problem (frequent redirection to rc.request based on odd subjects or body first-lines), instead of worrying with the specific recipies in rc.submit. (Since you're auto-creating lists, as I recall, you might consider unsetting it in rc.init instead, which will change the default bahevior of all SmartList lists.)
Charlie
smartlist@lists.rwth-aachen.de
-
Aaron Schrab -
Charlie Summers -
Greg Matheson -
violet＠torithoughts.org