Thanks Fritz for pointing out the NoAutoWhite. I knew it was there somewhere.
Thomas - thanks for the explanation on the 3rd option and the language clarification. Logical now. With .09, here's a real case example: One of our users gets alerts from Google when there Google finds something posted on a requested topic. The MAIL FROM is one of those unique [email protected] addresses. The from: line in the header is: From: Google Alerts <[email protected]> We have whitelisted the [email protected] address. With Nogreedy UNchecked, there are occasional messages that get flagged as bayesian. This isnt the only example of this that we're seeing. The other addresses on the emails are not redlisted. I reported this back on Oct 12, and it was promptly fixed with 0.5.04 ASSP 2.0.1 RC 0.5.04 fixed: - whitelisted from is not detected However, a subsequent release, and I don't know which one it was seems to have broken this again. All I know is that we're seeing the problem again with .09. We're not on .10 yet. Also, what do you think about my suggestion of spliting out what's necessary to detect a message that should be considered to be from a whitelisted sender and what sender addresses should be added to the whitelist when a message is considered as such? I'm not talking about recipient addresses (other recipients), but the sender addresses. On Sat, Oct 31, 2009 at 1:18 PM, Thomas Eckardt/eck <[email protected]> wrote: >>First, has the functionality been fixed in this version so that with >>NotgreeyWhitelist set to 0, a whitelisted FROM address in the header >>will consider a message to be whitelisted? This definitely wasn't >>working with .09. > > No this is/was not the case! But how ever, if a redlisted address was > found the feature was disabled without a hint! > > >>I'm obviously not understanding the logic > > A message gets white only if all found addresses are already whitelisted. > > "If set to 'check all addresses - all matches for white - add all', > all defined addresses in all of these fields have to match to get > white and all addresses will be added to or updated in whitelist." > > should be better > > "If set to 'check all addresses - all matches for white - update all', > all defined addresses in all defined fields must be already whitelisted > for a message to get a > whitelisted state and all addresses will updated in whitelist." > > > Thomas > > > > > > K Post <[email protected]> > 31.10.2009 17:54 > Bitte antworten an > ASSP development mailing list <[email protected]> > > > An > ASSP development mailing list <[email protected]> > Kopie > > Thema > [Assp-test] more on NotGreedyWhitelist > > > > > > > I've looked at 2.0.1 rc 0.5.10 and the new explanation of > NotGreedyWhitelist. I'd like some clarification. Once I understand > it better, I'll help to write up a clearer explanation for all. > > First, has the functionality been fixed in this version so that with > NotgreeyWhitelist set to 0, a whitelisted FROM address in the header > will consider a message to be whitelisted? This definitely wasn't > working with .09. > > Before this version, this was either on or off. Off was the "normal > operation" and when it worked (which wasn't the case with .09 and > various versions before that) if the mail-from or from, sender, > reply-to, etc > > So now, 0 is the default, and operates the same as the old default and > 1 is the same as having this checked before right? > > It the new option (2) that I'm confused about: > "If set to 'check all addresses - all matches for white - add all', > all defined addresses in all of these fields have to match to get > white and all addresses will be added to or updated in whitelist." > > It doesn't make sense to me that all have to match the whitelist in > order for them to be whitelisted - they're already all on the > whitelist. I'm obviously not understanding the logic or I'm not > understanding the explanation. > > While we're on this topic, might it be useful to have an option to > allow an address that is whitelisted already that appears in the > sender lines (from, reply-to, list-from, etc) in the message headers > to allow a message through WITHOUT adding the other addresses to the > whitelist? This would let us whitelist the from: address of a mailing > list, without worrying about getting every crazy unique mail from and > reply to in the whitelist. > > I don't think there's any point in having one time addresses like: > bounce-4vj3kjnvkjns43872.32344vlijnnsjknss552.5872...@whateverlist.com > go to the whitelist. These are usually one time use addresses that > identify the individual message that was sent. It's really the the > it's the from adress or list-from address in the header > [email protected] > that's matching the whitelist, and that's what we care about. > > What I'd like to see, or at lease discuss, is having 2 options to > replace the current NotGreedyWhitelist: > > 1) ConsiderMessageWhitelistedIf. This determines which address types > allow a message to be considered whitelisted. This doesn't set which > addresses will subsquently be whitelisted, just if the message whould > be considered to be from a whitelisted address in the first place. > Options could be: > 0: mail-from matches > 1: mail-from or any of the the sender headers like from: reply-to: > list-from: etc (if any one can match) > 2: mail-from AND any of the sender headers (all must match - seems > awefully strict to me due to the varying unique one time use from > addresses) > > > 2) AddOtherFromAddressesToWhitelist If a message is considered > whitelisted, determined by the settings in 1 above, should we add the > other sender addresses to the whitelist. options are Yes or No. > > If set to no, then if a message is whitelisted because the from: > address of [email protected] is already whitelisted, then the > message will be considered whitelisted from #1 above. BUT the one > time unique [email protected] wouldn't get added to the > whitelist. I think this makes a lot of sense, but would like the > experts' opinions. > > I believe that this would still let other recipient addresses (TO and > CC) be automatically whitelisted (as long as they are not a local > address or redlisted). I thought there used to be an option to turn > this on or off, but i can't find it. on is fine with me. > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Assp-test mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/assp-test > > > > > DISCLAIMER: > ******************************************************* > This email and any files transmitted with it may be confidential, legally > privileged and protected in law and are intended solely for the use of the > > individual to whom it is addressed. > This email was multiple times scanned for viruses. There should be no > known virus in this email! > ******************************************************* > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Assp-test mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/assp-test > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Assp-test mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-test
