Re: 3.2.0 release schedule
Duncan Findlay writes: On Wed, Jan 03, 2007 at 02:42:44PM +, Justin Mason wrote: - T + 0 days: announce a heads-up mail. clean up our corpora, get ready for mass-checking, try out mass-check to spot any big memory leaks or whatnot, fix remaining bugs that affect mass-checks (esp bug 5260!), get people signed up, enable all rules in svn. - T + 1 week, around a Thursday or so: start --bayes --net mass-checks; move to C-T-R. - T + 3 weeks, a Monday or so: hopefully finish mass-checks, bugs allowing ;) (note that includes two weekends.) - T + 3 weeks: perceptron runs, voting on new proposed scores, etc - T + 4 weeks and a bit: hopefully ready to release +1 BTW, how do we generate all 4 scoresets from one run? We used to have to do two runs, and I can't remember the rationale for that, or the rationale for doing it one. :-) Well, I took a look back at the 3.1.0 score-generation to figure this out, since I'd forgotten. Here are the old instructions: http://wiki.apache.org/spamassassin/RescoreDetails Basically, we do a single set3 mass-check, with all scores unzeroed. This uses --bayes --learn=35, which uses Bayes and learns 35% of all mails in whatever direction SpamAssassin classified them as (in other words, a pretty simplistic auto-learn algorithm, with errors). I think the idea was to simulate real Bayes auto-learning, which includes errors too. from that, we can derive: set-0: by removing all net and BAYES rules from the log set-1: by removing all BAYES set-2: by removing all net hits set-3: what we did The key appears to be the --learn=35 bit. It's hard to recall the details -- we didn't note much of it down I think, and it was 19 months ago :( --j.
Re: Moving on
Robert Menschel writes: Happy new year to all. As you may have gathered by my complete silence these last several months, I've been unable to contribute any time to SARE or SA. My time is taken up by other things right now, and it doesn't look like that's going to change for a while. So I'll be unsubscribing from all SARE and SA activity over the course of this month. The SA admin team may remove any/all committer and masscheck access for me at your convenience -- I won't be using them. Please feel free to redistribute anything I've worked on to anyone who wishes to work on it, and feel free to modify, rework, recreate, or destroy any of it. hi Bob -- sorry to hear it. :( Thanks for your contributions! For what it's worth, your committer status will remain intact, in case you find the time in future... here's hoping! --j.
zmi: check of some ham mails
hi Michael -- could you check these? They're in yr mass-check results and I think they're misfiled spam. these are hitting 'MIME_BOUND_EQ_REL', which otherwise has a 1.0 S/O, so I suspect they may be spams. The 2 hams also appear at the same time as the spams started appearing: http://ruleqa.spamassassin.org/20070114-r496037-n/MIME_BOUND_EQ_REL/detail?s_defcorpus=ons_g_over_time=1s_zero=onsrcpath=rulesrc%2Fsandbox%2Fjm%2F20_basic#overtime . 2 /tmp/masslearn_ham.29548.ZiF30054.mbox.40940940 EXTRA_MPART_TYPE,HTML_MESSAGE,MIME_BOUND_EQ_REL,TVD_RCVD_SPACE_BRACKET,UNPARSEABLE_RELAY,__ANY_IMAGE_ATTACH,__ANY_QUALCOMM_MUA,__CT,__CTYPE_HAS_BOUNDARY,__CTYPE_MULTIPART_ALT,__DOS_BODY_WED,__DOS_RCVD_MON,__DOS_RCVD_THU,__DOS_RCVD_WED,__DOS_REF_2_WK_DAYS,__DOS_REF_TODAY,__EUDORA_MSGID,__FB_IDENTITY,__FM_HOW_COST_ID,__FRAUD_ULK,__GIF_ATTACH,__GIF_ATTACH_1,__HAS_ANY_EMAIL,__HAS_ANY_URI,__HAS_MSGID,__HAS_RCVD,__HAS_SUBJECT,__HAS_X_MAILER,__INR_AND_NO_REF,__KAM_NUMBER2,__LOCAL_PP_NONPPURL,__MIME_BASE64,__MIME_HTML,__MIME_VERSION,__MISSING_REF,__MISSING_REPLY,__MISSING_THREAD,__MSGID_OK_DIGITS,__MSGID_OK_HEX,__MSGID_OK_HOST,__MSOE_MID_WRONG_CASE,__MULTIPART_RELATED,__NAKED_TO,__NONEMPTY_BODY,__PART_STOCK_CD_F,__SANE_MSGID,__TAG_EXISTS_BODY,__TAG_EXISTS_HTML,__TOCC_EXISTS,__TVD_INT_CID,__UNUSABLE_MSGID,__XM_QUALCOM time=1143069897,scantime=1,format=m,reuse=no Y 9 /tmp/masslearn_ham.29548.ZiF30054.mbox.54153124 DC_IMG_HTML_RATIO,DC_IMG_TEXT_RATIO,EXTRA_MPART_TYPE,HTML_IMAGE_ONLY_24,HTML_IMAGE_RATIO_02,HTML_MESSAGE,MIME_BOUND_EQ_REL,SUBJ_ALL_CAPS,TVD_RCVD_SPACE_BRACKET,UNPARSEABLE_RELAY,UPPERCASE_75_100,__ANY_IMAGE_ATTACH,__ANY_QUALCOMM_MUA,__CT,__CTYPE_HAS_BOUNDARY,__CTYPE_MULTIPART_ALT,__DOS_RCVD_MON,__DOS_RCVD_THU,__EUDORA_MSGID,__HAS_ANY_URI,__HAS_MSGID,__HAS_RCVD,__HAS_SUBJECT,__HAS_X_MAILER,__HTML_IMG_ONLY,__INR_AND_NO_REF,__JPEG_ATTACH_2P,__MIME_BASE64,__MIME_HTML,__MIME_QP,__MIME_VERSION,__MISSING_REF,__MISSING_REPLY,__MISSING_THREAD,__MSGID_OK_DIGITS,__MSGID_OK_HEX,__MSGID_OK_HOST,__MSOE_MID_WRONG_CASE,__MULTIPART_RELATED,__NAKED_TO,__NONEMPTY_BODY,__PART_STOCK_CD_F,__SANE_MSGID,__SUBJECT_ENCODED_QP,__SUBJECT_NEEDS_MIME,__TAG_EXISTS_BODY,__TAG_EXISTS_HTML,__TOCC_EXISTS,__TVD_INT_CID,__UPPERCASE_75_100,__XM_QUALCOM time=1164869648,scantime=1,format=m,reuse=no thanks! --j.
[Bug 5295] New: RFE: whitelist_authenticated
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5295 Summary: RFE: whitelist_authenticated Product: Spamassassin Version: SVN Trunk (Latest Devel Version) Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P5 Component: Libraries AssignedTo: dev@spamassassin.apache.org ReportedBy: [EMAIL PROTECTED] http://taint.org/2007/01/10/144318a.html#comments : Craig Hughes said: 'fwiw, whitelist_from_spf, whitelist_from_dkim, and whitelist_from_dk is a user nightmare. How about one list called whitelist_if_authenticated? Users dont have any frigging idea if the other end is spf, DKIM or DK. Actually, they probably dont know about authentication. How about whitelist_from and only apply the whitelist is authenticated? Actually, that latter thing is probably bad, in the case where the sender isnt doing auth, the receiver will think somethings broken if whitelisting doesnt work Maybe whitelist_from and whitelist_authenticated is the best ultimately probably moving to just whitelist_from where it only applies to authd mail once more senders are authing.' He's quite right too ;) So here's a feature request for whitelist_authenticated, which apes the UI of whitelist_from, but under the covers translates into all of: whitelist_from_spf, whitelist_from_dkim, whitelist_from_dk, and whatever other whitelist_from_xxx methods we may add in future, for the email addr specified. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 5295] RFE: whitelist_authenticated
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5295 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3200] new rules: dynamic/no-rDNS-for-IP
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3200 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2007-01-15 09:42 --- we now have similar rules in 3.2.0; RDNS_DYNAMIC and RDNS_NONE --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4712] random character replacement
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4712 --- Additional Comments From [EMAIL PROTECTED] 2007-01-15 09:45 --- is this still happening? can you attach a message that demonstrates this? it sounds like XMail is applying quoted-printable encoding. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3646] CPU over loaded
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3646 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2007-01-15 09:46 --- spamd requires a lot of CPU; you need to ensure your hardware can provide this. I suggest discussing on the users list first, then open a bug, if there really is a bug. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4805] Spamd error reading from spamd socket: Operation timed out
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4805 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2007-01-15 09:46 --- no followup -- closing --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 5231] bbmass mass-checks are seeing corrupt messages for some reason:
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5231 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|Undefined |3.2.0 --- Additional Comments From [EMAIL PROTECTED] 2007-01-15 09:56 --- ah, I'd already fixed this -- corrupt msgs in my mass-check logs --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 5187] RFE: try out new spamhaus PBL blocklist
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5187 [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|Future |3.2.0 --- Additional Comments From [EMAIL PROTECTED] 2007-01-15 10:00 --- RCVD_IN_PBL is already in the sandbox and being mass-checked, but should be moved to rules/20_dnsbl_tests.cf before release. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4664] found fetchmail marker, restarting parse breaks parsing instead
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4664 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2007-01-15 10:11 --- fixed in 3.2.0. [24649] dbg: metadata: X-Spam-Relays-Trusted: [24649] dbg: metadata: X-Spam-Relays-Untrusted: [ ip=58.33.222.11 rdns= helo=docemail.com by=mx.kundenserver.de ident= envfrom= intl=0 id=0MKsEO-1EYNUJ0w2E-0002RO auth= ] [24649] dbg: metadata: X-Spam-Relays-Internal: [24649] dbg: metadata: X-Spam-Relays-External: [ ip=58.33.222.11 rdns= helo=docemail.com by=mx.kundenserver.de ident= envfrom= intl=0 id=0MKsEO-1EYNUJ0w2E-0002RO auth= ] --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4909] Some PL_* rules match their names, so t/rule_names.t fails
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4909 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Target Milestone|Undefined |3.2.0 --- Additional Comments From [EMAIL PROTECTED] 2007-01-15 10:12 --- we've moved the (unmaintained) PL_* ruleset out to CustomRulesets on the wiki, hence rule_tests.t won't attempt to use those names. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4967] UNPARSEABLE_RELAY is prodigy.net
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4967 --- Additional Comments From [EMAIL PROTECTED] 2007-01-15 10:13 --- yeah, we'd definitely need to see a message with full headers (as an attachment). --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4770] use ASN data as Bayes token
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4770 --- Additional Comments From [EMAIL PROTECTED] 2007-01-15 10:14 --- I remove my veto. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 1948] spamd configuration from config file
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=1948 --- Additional Comments From [EMAIL PROTECTED] 2007-01-15 10:16 --- I'm still not a fan of the patch (due to the additional module requirement) --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 4770] use ASN data as Bayes token
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4770 --- Additional Comments From [EMAIL PROTECTED] 2007-01-15 10:23 --- cool -- thanks! will apply shortly --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: 3.2.0 release schedule
sure, +1.
Justin Mason wrote:
could you guys vote? I reckon, since it's part of an official release
plan, we need 3 committer +1's (mine plus two more).
--j.
Daryl C. W. O'Shea writes:
Sounds like an alright schedule to me. It'd be nice to get away with a
single RC, but I hope that we have enough people test it that we end up
doing a second one. :)
Daryl
Justin Mason wrote:
ping -- anyone there?
--j.
Justin Mason writes:
Happy new year! New year, time for a new major release since we missed
one in 2006 ;)
I think the 3.2.0 bugs list has most of the major ones off the list, and
the remaining either (a) don't need to be done for 3.2.0 necessarily or
(b) will probably be doable in the month or whatever between now and
release, in parallel with rescoring (feel free to shout if this is not the
case ;).
I've created http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5270 to
track the rescoring task.
First step, I think, is to define a schedule. How does this sound?
(based approximately on what we did for 3.1.0:
http://wiki.apache.org/spamassassin/Release310Schedule )
- T + 0 days: announce a heads-up mail. clean up our corpora, get ready
for mass-checking, try out mass-check to spot any big memory leaks or
whatnot, fix remaining bugs that affect mass-checks (esp bug 5260!),
get people signed up, enable all rules in svn.
- T + 1 week, around a Thursday or so: start --bayes --net mass-checks;
move to C-T-R.
- T + 3 weeks, a Monday or so: hopefully finish mass-checks, bugs
allowing ;) (note that includes two weekends.)
- T + 3 weeks: perceptron runs, voting on new proposed scores, etc
- T + 4 weeks and a bit: hopefully ready to release
Interesting URLs for what happened in the 3.1.0 rescoring:
http://wiki.apache.org/spamassassin/Release310Schedule
http://wiki.apache.org/spamassassin/RescoreMassCheck
http://wiki.apache.org/spamassassin/RescoreDetails
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4505
Here are the remaining 3.2.0 bugs fwiw, apart from bug 5270 (rescoring):
21 bugs found.
ID Sev Pri Summary
5155maj P1 make install always attempts to write to
/usr/local/lib...
5146nor P1 remove rule description translations out of
SpamAssassin ...
5269blo P2 may need to have separate mirror sets for differing
versi...
5235maj P2 SPF_FAIL on SMTP-authenticated mail relay
4493enh P2 add pre-tokenize text munge to learner
4820maj P3 The code for creating a new userstate_dir is severly
broken
4653min P3 bayes_pg.sql syntax error for old versions of PgSQL
(7.4.x)
5260maj P5 Memory leak persists in 3.2 DNS usage
3563nor P5 Odd errors if tieing Bayes DB while learning...
4078nor P5 Windows Hebrew encoding in subject not detected
4332nor P5 PMS-{redirect_num} unused / obfu redirection not
included
4435nor P5 Progress meter doesn't handle time left when it's in
the ...
4598nor P5 If DNS set available and it's not, hard failure occurs
4717nor P5 EnvelopeFrom option should be documented
4747nor P5 Problems with EnvelopeFrom auto-detection
4999nor P5 spamd --auth-ident trivial to bypass
5110nor P5 EXTRA_MPART_TYPE fires on valid multipart/related
5185nor P5 Bayesian learning uses different message checksums
during...
5257nor P5 push out autolearning thresholds for 3.2.0
4770min P5 use ASN data as Bayes token
--j.
Re: svn commit: r496501 - in /spamassassin/trunk: MANIFEST lib/Mail/SpamAssassin/Plugin/ASN.pm rules/v320.pre
[EMAIL PROTECTED] wrote: Author: jm Date: Mon Jan 15 13:32:42 2007 New Revision: 496501 Added: spamassassin/trunk/lib/Mail/SpamAssassin/Plugin/ASN.pm URL: http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin/Plugin/ASN.pm?view=autorev=496501 == --- spamassassin/trunk/lib/Mail/SpamAssassin/Plugin/ASN.pm (added) +++ spamassassin/trunk/lib/Mail/SpamAssassin/Plugin/ASN.pm Mon Jan 15 13:32:42 2007 @@ -0,0 +1,216 @@ I'm pretty sure the copyright isn't allowed by the ASF: +# @LICENSE +# Copyright 2006 dnswl.org, Matthias Leisi [EMAIL PROTECTED] Not sure about this: +=head1 AUTHOR + +Matthias Leisi [EMAIL PROTECTED], http://matthias.leisi.net/ Also... according to bugzilla, we don't have a CLA for this. Daryl
Re: svn commit: r496501 - in /spamassassin/trunk: MANIFEST lib/Mail/SpamAssassin/Plugin/ASN.pm rules/v320.pre
oops. well spotted... reverted for now. --j. Daryl C. W. O'Shea writes: [EMAIL PROTECTED] wrote: Author: jm Date: Mon Jan 15 13:32:42 2007 New Revision: 496501 Added: spamassassin/trunk/lib/Mail/SpamAssassin/Plugin/ASN.pm URL: http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin/Plugin/ASN.pm?view=autorev=496501 == --- spamassassin/trunk/lib/Mail/SpamAssassin/Plugin/ASN.pm (added) +++ spamassassin/trunk/lib/Mail/SpamAssassin/Plugin/ASN.pm Mon Jan 15 13:32:42 2007 @@ -0,0 +1,216 @@ I'm pretty sure the copyright isn't allowed by the ASF: +# @LICENSE +# Copyright 2006 dnswl.org, Matthias Leisi [EMAIL PROTECTED] Not sure about this: +=head1 AUTHOR + +Matthias Leisi [EMAIL PROTECTED], http://matthias.leisi.net/ Also... according to bugzilla, we don't have a CLA for this. Daryl
[Bug 4770] use ASN data as Bayes token
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4770 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #3790 is|0 |1 obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2007-01-15 14:13 --- Created an attachment (id=3826) -- (http://issues.apache.org/SpamAssassin/attachment.cgi?id=3826action=view) patch as applied oops. Daryl just pointed out -- we need to sort out a CLA first... Matthias, could you fax through a CLA? http://www.apache.org/licenses/#clas --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: 3.2.0 release schedule
On Wed, Jan 03, 2007 at 02:42:44PM +, Justin Mason wrote: First step, I think, is to define a schedule. How does this sound? (based approximately on what we did for 3.1.0: http://wiki.apache.org/spamassassin/Release310Schedule ) - T + 0 days: announce a heads-up mail. clean up our corpora, get ready for mass-checking, try out mass-check to spot any big memory leaks or whatnot, fix remaining bugs that affect mass-checks (esp bug 5260!), get people signed up, enable all rules in svn. Ok. - T + 1 week, around a Thursday or so: start --bayes --net mass-checks; move to C-T-R. Did we really whittle it down to a single mass-check? I could have sworn there were still at least 2 required. IMO, I'd hold off on CTR as long as possible. Being a major release, I'd like to give as much time in pre-release/CTR state as possible. - T + 3 weeks, a Monday or so: hopefully finish mass-checks, bugs allowing ;) (note that includes two weekends.) - T + 3 weeks: perceptron runs, voting on new proposed scores, etc - T + 4 weeks and a bit: hopefully ready to release There's no testing time in here. Around T+0 I'd recommend doing a pre-release cycle, we can work through that while doing the mass-checks. So far there are probably only enough people running 3.2 that I could count them on one hand, so a wider test would be good. After the scores are set, we should do a final RC set of releases just to make sure, then the full release after that. -- Randomly Selected Tagline: Bread has been proven to absorb water. Since the human body is more than 90 percent water, it follows that eating bread could lead to your body being taken over by this absorptive food product, turning you into a soggy, gooey bread-pudding person. - http://www.geoffmetcalf.com/bread.html pgp9ExPcyw6Uj.pgp Description: PGP signature
Re: 3.2.0 release schedule
Theo Van Dinter writes: On Wed, Jan 03, 2007 at 02:42:44PM +, Justin Mason wrote: First step, I think, is to define a schedule. How does this sound? (based approximately on what we did for 3.1.0: http://wiki.apache.org/spamassassin/Release310Schedule ) - T + 0 days: announce a heads-up mail. clean up our corpora, get ready for mass-checking, try out mass-check to spot any big memory leaks or whatnot, fix remaining bugs that affect mass-checks (esp bug 5260!), get people signed up, enable all rules in svn. Ok. - T + 1 week, around a Thursday or so: start --bayes --net mass-checks; move to C-T-R. Did we really whittle it down to a single mass-check? I could have sworn there were still at least 2 required. I know, I thought so too -- but looking back through 3.1.0 history, I can find only one. given the --learn thing, it seems fine. IMO, I'd hold off on CTR as long as possible. Being a major release, I'd like to give as much time in pre-release/CTR state as possible. OK, fine with that. - T + 3 weeks, a Monday or so: hopefully finish mass-checks, bugs allowing ;) (note that includes two weekends.) - T + 3 weeks: perceptron runs, voting on new proposed scores, etc - T + 4 weeks and a bit: hopefully ready to release There's no testing time in here. Around T+0 I'd recommend doing a pre-release cycle, we can work through that while doing the mass-checks. So far there are probably only enough people running 3.2 that I could count them on one hand, so a wider test would be good. ok, prerelease at T + 0 makes sense -- agreed. After the scores are set, we should do a final RC set of releases just to make sure, then the full release after that. ok. so something like this? - T + 0 days: issue prerelease. announce a heads-up mail. clean up our corpora, get ready for mass-checking, try out mass-check to spot any big memory leaks or whatnot, fix remaining bugs that affect mass-checks (esp bug 5260!), get people signed up, enable all rules in svn. - T + 1 week, around a Thursday or so: start --bayes --net mass-checks. - T + 3 weeks, a Monday or so: hopefully finish mass-checks, bugs allowing ;) (note that includes two weekends.) - T + 3 weeks: perceptron runs, voting on new proposed scores, etc. how's about C-T-R once the new scores are applied? then final RC set of releases... - T + N weeks: once we are happy with an RC (so N could be any number 3), redo that RC as a full release. --j.
[Bug 5250] Incorrect behavior with 8-bit messages
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5250 --- Additional Comments From [EMAIL PROTECTED] 2007-01-15 22:49 --- how long time need for include this fix? --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
