User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20070309 Firefox/22.214.171.124 Build Identifier: version 126.96.36.199 (20070326) I have the trust junk mail headers set by Spamassassin setting turned on, and have set the move new junk messages to a spam folder option. When messages arrive, only about 1 in 10 is correctly filed in my Spam folder. The rest end up in my Inbox, and are not marked as Junk by Thunderbird. These messages have ***SPAM*** in the subject line, and have the Spamassassin headers: X-Spam-Score: 5.514 X-Spam-Level: ***** X-Spam-Status: Yes, score=5.514 required=3.5 tests=[BAYES_99=3.5, HTML_IMAGE_ONLY_16=0.338, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=1.675] I have tried deleting my .thunderbird directory and setting up a new account with no filters or extensions, but the problem persists. I am pulling mail from a POP3 server (dovecot) using TLS. Reproducible: Sometimes Steps to Reproduce: 1. Check mail from a spamassassin-equipped server. 2. Mail that is tagged as spam will not be moved to junk folder or tagged as junk. 3. Expected Results: Mail labeled as spam should have the Thunderbird junk flag set, and be moved to the Junk folder. I can work around this by creating my own filter to move the messages, but this causes problems with the email notification. Specifically, I get the beep/popup for incoming spams.
Do you use the "Enable adaptive junk mail controls for this account" too? Does the junk filter log show anything interesting?
Version: unspecified → 2.0
Yes, adaptive junk mail controls are active. I turned on the junk filter log and checked mail. Six messages tagged as spam arrived, of which two were correctly put in the junk folder and four were left in my inbox. The two that got moved to the junk folder were logged in the junk log, i.e.: Detected junk message from Clint Chambers <email@example.com> - ***SPAM*** The other four were not logged in the junk log or the message filter log.
I have also been having problems with the trust spamassassin headers option. I suspect that for Brian, his mails are being determined as junk by Thunderbird's built-in adaptive junk mail controls and not from the Spamassassin headers. I have enable adaptive controls turned off and trust headers set by Spamassassin turned on. Thunderbird never marks messages as junk. If I manually set the junk flag in Thunderbird and then run Run Junk Mail Controls on Folder it removes the junk flag. This says to me that Thunderbird is looking for something different in the headers than what I have. My headers are as follows: X-Spam-Flag: YES X-Spam-Level: ++++++ X-Spam-Status: Yes, score=6.9 required=5.0 autolearn=no version=3.1.7-deb host=aurora.northfolk.ca * 0.0 DK_POLICY_SIGNSOME Domain Keys: policy says domain signs some mails * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID <<<snip>>> I posted to the forums with no response: http://forums.mozillazine.org/viewtopic.php?p=2888775&sid=3bd6af8c1b5cc0a614c1e35138442abd As well I found this in the forums: http://forums.mozillazine.org/viewtopic.php?p=2868484&sid=281eaf441ab9b80b6a7112ccf3421488 There is confusion as to exactly what Thunderbird is looking for in the headers.
Just wanted to add that I'm experiencing the exact same problems. I have Spamassassin for Ubuntu installed with my own settings and filters... but I never changed how SA creates headers. Here's an example of my headers: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on botch.flensborg X-Spam-Level: ************************************ X-Spam-Status: Yes, score=36.5 required=5.0 tests=BAYES_99,DRUGS_ANXIETY, DRUGS_ANXIETY_EREC,DRUGS_DIET,DRUGS_ERECTILE,HTML_MESSAGE, MIME_HTML_MOSTLY,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_SORBS_WEB,RCVD_IN_XBL, SARE_ADULT2,SARE_WEOFFER,SPF_SOFTFAIL,UNPARSEABLE_RELAY, URIBL_AB_SURBL,URIBL_BLACK,URIBL_JP_SURBL,URIBL_OB_SURBL, URIBL_SC_SURBL,URIBL_WS_SURBL autolearn=spam version=3.1.7 I have had all my spam removed so far after enabling adaptive junk filters, but I don't know if that's due to the adaptive filters reading SA headers. I'll know once I catch an SA-marked message in my inbox again... and if I don't, I guess you'll have to have adaptive junk controls enabled to enable trusting SA headers.
Some SA-marked messages were left out by my adaptive junk filter, so I'm back to this conclusion: Trust SpamAssassin option is totally defunct. So I tried to add a filter manually. It read: version="8" logging="no" name="SpamAssassin2" enabled="yes" type="1" action="Move to folder" actionValue="imap://benjamin@mymailserver/INBOX/Junk" condition="OR (\"X-Spam-Status\",begins with,Yes) OR (\"X-Spam-Flag\",is,YES)" The default SpamAssassin filter (SpamAssassin.sfd): version="8" logging="yes" name="SpamAssassinYes" enabled="yes" type="1" action="JunkScore" actionValue="100" condition="OR (\"X-Spam-Status\",begins with,Yes) OR (\"X-Spam-Flag\",begins wit h,YES) OR (subject,begins with,***SPAM***)" name="SpamAssassinNo" enabled="yes" type="1" action="JunkScore" actionValue="0" condition="OR (\"X-Spam-Status\",begins with,No)" I don't think the defualt filter is the issue. But I discovered something even stranger: When I try to manually run my new SpamAssassin2 filter, nothing happens! Tools->Run Filters On Folder does absolutely nothing, and the SpamAssassin2 filter is the only one I have configured.
I did some experimenting with the filtering and what I found was that for IMAP, filtering only works on the pre-defined headers: Subject, To, From, etc. For local folders I was able to make a filter that set the junk flag based on the X-Spam-Flag header. I used the built-in filter editor for this. I believe that Benjamin tried his custom filter on an IMAP folder. For both IMAP and local folders, "Run Junk Mail Controls on Folder" (with only trust Spamassassin selected) has no effect. So it appears that trust Spamassassin does not work at all and the filters only work properly on locally stored mail. I am using Thunderbird 188.8.131.52 on Windows XP, so this problem is not limited to the Linux build of the original poster.
That's bug 184490...
I can confirm that I use IMAP, so it seems very likely that this is bug #184490, which has apparently worsened. In short, I believe that TB 2.0 doesn't filter out SA headers on an IMAP server.. apparently because it's unable to cache special types of headers on IMAP messages?
Ah, very sorry. Forgot to add the good part: That TB is in fact able to run my custom filter on new incoming mail - just not via Tools->Run Filter On Folder. So everybody who has problems with "Trust SA Headers" can use a custom filter as a temporary fix.
->NEW I turned off the thunderbird adaptive filtering, and enabled only trust SpamAssassin. After that, no mail is marked as junk, though SpamAssassin clearly says that it is. This was an IMAP account (windows).
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Summary: Trust Spamassassin option is not working reliably in Thunderbird 2.0 → Trust Spamassassin option is not working in Thunderbird 2.0
I confirm this bug (Thunderbird 2.0 for Mac OS X), IMAP account. Even though I was able to make it work through message filters, I would very much prefer built-in junk control, as it can protect mail coming from senders that are in the address book. Message filters are primarily for sorting mail into folders rather than fighting the spam. Example of my spam headers: X-????????-MailScanner-SpamCheck: spam, SpamAssassin (not cached, score=30.523, required 6, autolearn=spam, BAYES_99 3.50, DRUGS_ERECTILE 0.49, DRUG_ED_ONLINE 2.70, HTML_50_60 0.13, HTML_MESSAGE 0.00, IMPOTENCE 0.63, RCVD_IN_NJABL_DUL 1.95, SUBJECT_DRUG_GAP_C 0.61, UNRESOLVED_TEMPLATE 1.32, URIBL_AB_SURBL 3.81, URIBL_JP_SURBL 4.09, URIBL_OB_SURBL 3.01, URIBL_SBL 1.64, URIBL_SC_SURBL 4.50, URIBL_WS_SURBL 2.14) X-????????-MailScanner-SpamScore: ssssssssssssssssssssssssssssss X-Spam-Status: Yes
I confirm this bug (Thunderbird 184.108.40.206 (20070604) / Ubuntu 7.04). I'm using POP3. One example-header: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on cerveza.tgc.at X-Spam-Level: ********* X-Spam-Status: Yes, score=10.0 required=5.0 tests=DATE_IN_PAST_06_12, FROM_LOCAL_NOVOWEL,HELO_DYNAMIC_DHCP,HELO_DYNAMIC_IPADDR autolearn=no version=3.1.7-deb
Spamassassin scores spam correctly. I run TB version 220.127.116.11 (20070728) as an IMAP client under XP Pro with all updates applied. I have set Trust SA Headers. It ignores them. X-Spam-Status: Yes, score=11.1 required=5.0 tests=HTML_IMAGE_ONLY_04, HTML_MESSAGE,HTML_SHORT_LINK_IMG_1,MISSING_SUBJECT,MPART_ALT_DIFF, RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_SORBS_DUL,RCVD_IN_XBL autolearn=no version=3.1.7-deb
Odd, but perhaps related, bug 394244 claims cases where this works only with the default account. Christian, do you see this also with the default account? And did this work for you in 1.5 updates prior to 18.104.22.168? me: version 22.214.171.124pre (20070922), consistently fails default account
i have to agree wayne. i use version 126.96.36.199 (20070806) and it doesn't work for my default account as well.
I've been running a couple days with _trunk_ build version 3.0a1pre (2007100604) and "trust" works fine, after I restarted thunderbird. (my junk folder is set to local/junk because I can't get TB to recognize my imap junk folder as "special".) what do you all see in the error console, eg bug 398864 comment 1? does it work for you if you set a local folder to be your junk target?
(In reply to comment #14) > And did this work for you in 1.5 updates prior to 188.8.131.52? The behavior was the same in the versions before. > Christian, do you see this also with the default account? My default account doesn't have SA-Flags so i experimented and found 2 things: * no, it doesn't happen with the default account. messages with SA-flag are recognized as spam always. * it was (probably) my fault, that the other accounts didn't work. At "Configure Junk Settings for:" I can choose - "Lokale Ordner" - account 1 - account 2 - account n Now it seems to me, that the settings done in "Lokale Ordner" affectc "account 1" but not the other ones! When I mark "Trust junk mail headers ..." explicitly for account2, it works like expected. So, in my case, it wasn't "a bug" but user error because of misleading UI.
I'm another user reporting similar problems. I'm using Thunderbird version 184.108.40.206 (20070728) and on the server Spamassassin 3.002003. I'd be happy to provide any other information that would help in debugging. The following headers are on a sample message: X-Spam-Status: Yes, score=16.4 X-Spam-Score: 164 X-Spam-Bar: ++++++++++++++++ X-Spam-Report: Spam detection software, running on the system "<omitted)", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Dear valued member.Don't miss our Huge Sale - up to 20% off the price for qualitative generic Canadian drugs.Canadian drugs are as qualitative as the American ones but they are a lot cheaper. Well, actually they used to be cheaper… Now the prices for generic Canadian drugs are just laughable. Up to 20% off the price for qualitative products of Canadian subsidiaries of world's major pharmaceutical companies.Check out our New Specials right now. With best regards, Zelma Hatch [...] Content analysis details: (16.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see <http://www.spamcop.net/bl.shtml?220.127.116.11>] 2.9 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL [18.104.22.168 listed in zen.spamhaus.org] 0.0 HS_INDEX_PARAM URI: Link contains a common tracker pattern. 0.0 HTML_MESSAGE BODY: HTML included in message 1.8 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 2.9 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist [URIs: typerich.cn] 2.1 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist [URIs: typerich.cn] 2.5 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist [URIs: typerich.cn] 2.0 URIBL_BLACK Contains an URL listed in the URIBL blacklist [URIs: typerich.cn] X-Spam-Flag: YES
Replies needed (this is in follow up, in part, to comment 10) - in version 1.5, do you have "enable adaptive" UNCHECKED and "trust" was working? - in 2.0, do you have junk mail control enabled AND marking junk, only the "Trust" part is NOT working? This also doesn't work for me on an existing profile using 22.214.171.124 and bienvenu determined TB was not requesting the X-Spam-Flag: header from the server. But it does work for me on a new profile, ONLY if I have adaptive enabled, and only after I have manually marked as least one piece of mail as junk. (In reply to comment #9) > Ah, very sorry. Forgot to add the good part: That TB is in fact able to run my > custom filter on new incoming mail - just not via Tools->Run Filter On Folder. > So everybody who has problems with "Trust SA Headers" can use a custom filter > as a temporary fix. custom filter did not work for me on the existing profile, so workaround might not work for everyone
(In reply to comment #19) > determined TB was not requesting the X-Spam-Flag: header from the server. > But it does work for me on a new profile, ONLY if I have adaptive enabled, and > only after I have manually marked as least one piece of mail as junk. For testing I turned off the adaptive junk filtering, and only used the trust spamassassin. If both are enabled it's hard to know which has recognized the junk.
Here is my understanding of how this all works, which should help you. The order of processing is 1. filters 2. "trust header" 3. "adaptive junk" (aka jmc) "trust header" is in fact just an ordinary filter, stored in the program directory at <install-dir>\isp and defined at http://mxr.mozilla.org/mozilla/source/mailnews/base/search/src/SpamAssassin.sfd You can see from the definition that SpamAssassin.sfd causes filters to mark "spam" messages as junk (and thus moved accordingly). This also means that the junk training data is being fed by messages that have been filtered as being spam (which I don't really like ). The bottom line is this - messages that match "trust" are identified strictly by filter, not jmc, and the actions are found in the filter logs (if turned on)  I would prefer to see the connection between "trust junk mail headers" and adaptive be optional, i.e. I prefer these messages not marked as junk. I won't get into the reasons, but I personally don't use trust preferring instead to filter on subject "[SPAM]". You could also do this, as noted earlier, by setting a custom filter for X-Spam-Flag: header -- when it works.
>This also means that the >junk training data is being fed by messages that have been filtered as being >spam (which I don't really like ). Do you mean that the junk messages get put in the same junk folder? The junk training data is not affected at all by the "trust" filters or messages which have been marked as good or bad by the server-side filter - if a message is marked as good or bad by the trust filters, that message isn't passed to the junk mail filter at all. In my case, I have jmc turned off for my imap server, but we're still fetching the x-spam headers required by the filter, so I don't think you need jmc turned on in order to have the trust filters work.
(In reply to comment #22) > >This also means that the > >junk training data is being fed by messages that have been filtered as being > >spam (which I don't really like ). > > Do you mean that the junk messages get put in the same junk folder? The junk > training data is not affected at all by the "trust" filters or messages which > have been marked as good or bad by the server-side filter - if a message is > marked as good or bad by the trust filters, that message isn't passed to the > junk mail filter at all. in my case I set "move junk to local folder", the message is marked junk. but you are saying training data was not affected (even with jmc turned on) ... that the message is only flagged in the header. seems counterintuitive.
I would report the same issue here: _ I use an IMAP account. _ SpamAssassin is on the mail server (Communigate Pro). _ The "trust" option does not work at all. _ Using a custom filter does not work.
Why its asking for blocking-thunderbird3? Does it happen on trunk?
(In reply to comment #25) > Why its asking for blocking-thunderbird3? Magnus requested without comment > Does it happen on trunk? not according to my comment 16 (which happened after "blocking-thunderbird3?") - but I haven't retested
Can't recall if I actually tested with trunk earlier, but I did some more testing now. It works fine on trunk, but with tb2 it certainly doesn't work at all - tested both imap and pop.
Assignee: mscott → nobody
Whiteboard: [strictly tb2 - trunk is fine]
How about one of you great and good people just removing the option? That way no-one will actually care any more?
This is no solution. The right decision would be to make it working. David, could you point me to a class where the filtering is done? Is it the same like other message filters?
I did a test some minutes ago. I deactivated the adaptive junk mail controls within the account settings of my POP3 account. After getting new a new mail which is marked as SPAM by Spamassassin it is moved into the junk folder. Same happens several times now and I cannot reproduce this problem with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:126.96.36.199pre) Gecko/20080113 Thunderbird/188.8.131.52pre Mnenhy/0.7.5.0 ID:2008011403 My headers look like: X-Spam-Status: Yes, hits=5.4 tagged_above=-999.0 required=5.0 tests=BAYES_60, FROM_ENDS_IN_NUMS, MISSING_SUBJECT, MSGID_FROM_MTA_HEADER X-Spam-Level: ***** X-Spam-Flag: YES IS anyone of you, who sees this problem, be able to create a fresh profile for testing? Please also explain the steps you did.
I believe I know why this happens now. In my preferences, I have an entry mail.server.default.serverFilterName with a value of SpamAssasin (which was an old misspelling bug). But the filename for the filter is spelled correctly in TB 2.0, that is SpamAssassin.sfd If you change the preference value to SpamAssassin then filtering starts to work. The best way to test filtering is to send yourself a message that has subject ***SPAM*** as that will be detected by the SpamAssassin filters. The error, at least for new profiles, is in mailnews.js Bug 378340 corrected the misspelling on trunk.
Maybe there are several issues, but the misspelling isn't an issue for me. STR (tb2 only, trunk is ok): 1) make a fresh profile 2) set up an imap account (pop should do to, didn't try this time) 3) account junk settings: uncheck enable adaptive... and select trust spamassassin 4) send yourself a msg with subject "***SPAM*** testing spamassassin" - no quotes 5) observe the received mail, which is *not* marked as junk Tested on linux.
If I repeat your process (but Windows and POP3) I get the same result. Fix misspelling, still not marked as SPAM. Exit TB, restart, NOW it is marked as SPAM.
(That is, after I resend and receive another email.)
(In reply to comment #32) > 3) account junk settings: uncheck enable adaptive... and select trust > spamassassin Adaptive junk mail control doesn't have to be enabled to test the spam assassin headers. > 4) send yourself a msg with subject "***SPAM*** testing spamassassin" - no > quotes That should really work? I don't think so. I haven't taken a look at the source but I cannot imagine that we trust the subject header. Instead you should add the X-Spam-% headers.
http://lxr.mozilla.org/mozilla1.8/source/mailnews/base/search/src/SpamAssassin.sfd has: condition="OR (\"X-Spam-Status\",begins with,Yes) OR (\"X-Spam-Flag\",begins with,YES) OR (subject,begins with,***SPAM***)"
Henrik: yes, that's why I turned it off;) It's easier to test with the spam subject, since many servers remove incoming X-Spam headers. (And in fact one I have removed the spam subject too. ) Ok, I too can get it to work like comment 33. So this is bug 378340 biting then... will ask approval for that.
The subject doesn't work at any time. For myself I changed it to "[SPAM]" a while ago. In that case the subject wouldn't match. But if servers also remove X-Spam headers it's even not better. I should redo my changes and use SpamAssassins default value. Thanks. Because it was already fixed on Trunk a while ago and the patch on bug 378340 will also do it on branch, let us dupe this bug against bug 378340. Thanks everyone for your help to identify the cause.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
It's not a duplicate, that's just a workaround for the broken-as-designed account settings pane.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
am-junk only saves a per-server value for mail.server.whichever.serverFilterName if you change from the one that's selected when you open the pane and check the box to trust server headers, otherwise it falls back to mail.server.default.serverFilterName. That would hypothetically be nice if you were using an app that you got from your ISP, and they changed default.serverFilterName when they decided to switch from one to another, but if you install an extension that changes default.serverFilterName to foopygoats and includes foopygoats.sdf in its extensions/ directory, then when you uninstall it because you want to trust SpamAssassin instead, you'll look at the account junk settings pane, see that trust SpamAssassin is selected, and never imagine that changing the value to SpamPal, then back to SpamAssassin, without even needing to save in between, will magically make it start working. And that, by the way, is the workaround for Tb 2.x if you don't want to fix the value of the default pref but want it to work before bug 378340 lands for 184.108.40.206: change to SpamPal, then back, and we'll save a pref for that particular account to trust SpamAssassin rather than falling back to the default of trusting SpamAssasin with one s and then not finding it to trust.
Status: REOPENED → NEW
Component: General → Account Manager
QA Contact: general → account-manager
Whiteboard: [strictly tb2 - trunk is fine]
Version: 2.0 → Trunk
On second thought, though, my extension scenario would need the extension to do something stupid, since if it just sets the default in its defaults/preferences/, then its changed default would go away when it did. Maybe there isn't a way for it to be broken without someone being foolish.
I think we really need a Thunderbird 2.5 with these junk mail/spam issues all fixed. This was expected for before 2.0, and to wait for 3.0 is too far away.
Worcester12345: When you say "these junkmail/spam issues" what are you referring to?
->FIXED now that bug 378340 landed on branch. If someone still have problems with this in tb220.127.116.11 or later, feel free to reopen and provide steps to reproduce.
Status: NEW → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Version: Trunk → 2.0
Magnus, are you really sure? As Phil stated in comment 39 this is only a workaround. That's why it's also not a dupe of bug 378340.
Well, I don't know what there would be left to do in this bug. (Unless there were other issues, but I don't think so.) With the branch landing the pref will get set to the correct value (also for users getting bitten by it now.)
Ok, that really seems to work now. During my tests I deleted my spamassassin.sfd. But now the file is not copied again to my profile. Is this the expected behavior? The filtering works anyway.
As Phil said, this is not fixed by bug 378340. If you get a filter file from your isp and you put it into the isp folder of Thunderbird you can chose this entry from within the preferences. The default.filterName within mailnews.js shouldn't be changed to reproduce this bug. All works fine until the sfd file is removed. If you restart Thunderbird it shows "SpamAssassin" as trusted filter. But within the prefs.js we still have the old filter name. It's not filtering until you select SpamPal and go back to SpamAssassin. Reopen bug and setting it back to trunk.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: Trust Spamassassin option is not working in Thunderbird 2.0 → Trust Spamassassin option is not working in Thunderbird
Version: 2.0 → Trunk
The problem is here: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/mailnews/base/prefs/resources/content/am-junk.js&rev=1.12&mark=82-85#80 We are setting the menulist value to the filter name from the prefs.js. But one step further if we don't have selected any entry we set the selectedIndex to 0 which forces "SpamAssassin" to be shown. We should compare the current filter name with the list of available filters. If no such filter is installed anymore we should update to SpamAssassin and perhaps deactivating the checkbox. Users will notice that there was a change and have to activate it again with the correct filter name set.
Though if I'd really thought about it, I would have filed a new bug instead of dragging this cc and voter list through the "is this different enough to behave differently?" question. I think we have other things where we use this same pattern of "if you choose to use the value that's the default right now, you aren't choosing that value, you're choosing to use the default value, whatever it may change to in the future," but I don't think we do it with other things where it's so easy for the default to not be found, making it look like you are selecting the first value that is found, when in fact you aren't.
Summary: Trust Spamassassin option is not working in Thunderbird → If .sdf file for .default.serverFilterName isn't found, we don't save a pref for the first one that is found
perhaps, but no casual user is now going to find the symptom on a bug search now. modding summary
Summary: If .sdf file for .default.serverFilterName isn't found, we don't save a pref for the first one that is found → If .sdf file for .default.serverFilterName isn't found, we don't save a pref for the first one that is found - example: Trust Spamassassin option is not working
Oooookay. How about if I just file a bug when I have a patch, so we don't have to keep mauling this one, then?
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → DUPLICATE
Summary: If .sdf file for .default.serverFilterName isn't found, we don't save a pref for the first one that is found - example: Trust Spamassassin option is not working → Trust Spamassassin option is not working
Status: RESOLVED → VERIFIED
(In reply to comment #43) > Worcester12345: When you say "these junkmail/spam issues" what are you > referring to? It generally doesn't work all that well at all. Maybe it all falls under this one. I won't know until I get a chance to check it out. Spam blocking has been a big letdown in 2.0.
You need to log in before you can comment on or make changes to this bug.