| View previous topic :: View next topic |
| Author |
Message |
paolo73an
Joined: 04 Sep 2006
Posts: 29
|
 Posted: Sun Sep 17, 2006 7:57 am Post subject: Advice needed for black rule creation |
 |
|
Hello, I'm a new user of Antispamsniper. I have the licensed version 1.6.7.2 of the plugin.
I need to classify as spam all messages directed to malformed email addresses of specified domain. I have 2 trusted domains to which several messages are sent to random names before @.
In particular I need to classify spam according to the following 2 rules (I'll put fake names for privacy):
1- I need to block all incoming messages sent to domain example.it where the field To is different from info@example.it or from support@example.it
2- I need to block all incoming messages sent to domain example2.it where the field To is different from info@example2.it
In both cases names before @ can be any sequence of characters and digits
Please help me because I'm not so confident with regular expressions syntax...thanks
Bye
Paolo from Italy |
|
| Back to top |
|
 |
JimKyle
Joined: 07 Aug 2006
Posts: 16
Location: Oklahoma City, OK, USA
|
| Posted: Sun Sep 17, 2006 6:05 pm Post subject: |
|
|
Here's the best reference for regular expression syntax I've yet found:
http://www.regular-expressions.info/reference.html
The same site has a tutorial, and the author of the site has several products to help set up regular expressions that look very interesting.
For your specific examples, I believe that the NOT checkbox will be the secret of generating the rules. For example2, just type in the address, then click the NOT checkbox. For example 1, put two lines in the rule, one for each address, and on both, click NOT.
Note that I've not tested this, and I don't consider myself an expert on either REs or the Sniper, but it's worth a try. Do NOT check the STRONG checkbox on either of the rules; it's unnecessary when you have only one line in the rule, and would defeat the rule completely when you have the two.
Another solution might be to create STRONG white rules for each of the two addresses, then create a black rule to reject "@example.it" messages. Since the white rules are processed first, and if satisfied the black rules would never be hit for that message, this should accomplish your goal.
I have a similar problem but it's compounded because I create dummy names when registering products or joining forums (my mail address here is different from what I use anywhere else, but still in my domain) so I pretty well have to accept all messages addressed to my domain, or at least use something other than the "TO" address to filter the bad ones out. |
|
| Back to top |
|
|
daveg
Joined: 06 Aug 2006
Posts: 8
Location: Sarasota, FL, US
|
| Posted: Sun Sep 17, 2006 6:55 pm Post subject: Re: Advice needed for black rule creation |
|
|
| paolo73an wrote: | | Please help me because I'm not so confident with regular expressions syntax...thanks |
This does not answer your specific questions, but if you're new to regular expressions you might have a look at "Regex Coach". This is a small graphical program that allows you to type in regular expressions, experiment with them, and immediately see the results. Highly recommended.
Available at http://weitz.de/regex-coach/, along with a small tutorial on its use. Free, but a small donation might be in order. |
|
| Back to top |
|
|
paolo73an
Joined: 04 Sep 2006
Posts: 29
|
| Posted: Sun Sep 17, 2006 7:48 pm Post subject: Re: Advice needed for black rule creation |
|
|
| daveg wrote: |
This does not answer your specific questions, but if you're new to regular expressions you might have a look at "Regex Coach".... |
Thanks daveg I'll give a look at the proggie, but I'm wondering if what I asked can be done or not with regular expression, so if someone could post a black rule (if exists) to block malformed destination address to trusted domain, it would be greatly appreciated. |
|
| Back to top |
|
|
paolo73an
Joined: 04 Sep 2006
Posts: 29
|
| Posted: Sun Sep 17, 2006 9:40 pm Post subject: |
|
|
| JimKyle wrote: |
Another solution might be to create STRONG white rules for each of the two addresses, then create a black rule to reject "@example.it" messages. Since the white rules are processed first, and if satisfied the black rules would never be hit for that message, this should accomplish your goal. |
I tried with the combination of white/black rules as you suggested.
It works, thanks
Bye |
|
| Back to top |
|
|
paolo73an
Joined: 04 Sep 2006
Posts: 29
|
| Posted: Mon Sep 18, 2006 5:29 am Post subject: |
|
|
Sorry for bothering you again but I've noticed 2 things I don't like much
1- with the combination white/black rules, I see in the log window that spam messages are classified as ham. Maybe the final result is good in the sense that the message is then deleted, but the black rule behaviour doesn't appear in the log and worst of all the spam message is classified as good
2- using the "not" syntax with the trusted address, makes all other messages be classified as spam.....
any further trick? |
|
| Back to top |
|
|
JimKyle
Joined: 07 Aug 2006
Posts: 16
Location: Oklahoma City, OK, USA
|
| Posted: Mon Sep 18, 2006 1:12 pm Post subject: |
|
|
I think that your first point reveals a bug in the Sniper, or maybe just a logical oversight in the program design. Perhaps there needs to be another option, similar to the automatic learning for friendly addresses, so that any message satisfying a black rule gets learned as spam. It's definitely not right for a message that's rejected by a rule be learned as ham!
Your second point reveals a logic mistake on my part. Re-examining just what the two NOT lines would do shows that any message that isn't from one of the two accepted "example.it" addresses would be rejected. Possibly adding another line to the rule to require the From to contain "@example.it" (just like the three-rule solution) could overcome this and make it work as intended -- and it might also keep the rejected messages from being learned as ham.
Do you have the "friendly address" options set up to learn automatically? That might be what is forcing the wrong-learning situation... |
|
| Back to top |
|
|
paolo73an
Joined: 04 Sep 2006
Posts: 29
|
| Posted: Mon Sep 18, 2006 3:38 pm Post subject: |
|
|
| JimKyle wrote: | | I think that your first point reveals a bug in the Sniper, or maybe just a logical oversight in the program design. Perhaps there needs to be another option, similar to the automatic learning for friendly addresses, so that any message satisfying a black rule gets learned as spam. It's definitely not right for a message that's rejected by a rule be learned as ham! |
I completely agree with you.
| JimKyle wrote: |
.....
Your second point reveals a logic mistake on my part. Re-examining just what the two NOT lines would do shows that any message that isn't from one of the two accepted "example.it" addresses would be rejected. Possibly adding another line to the rule to require the From to contain "@example.it" (just like the three-rule solution) could overcome this and make it work as intended -- and it might also keep the rejected messages from being learned as ham.
..... |
I don't think what you say would work....
that's because I have multiple mail accounts and the black rules are applied to all, not only to the account related to @example.it....
In that way I don't think to insert the rule you suggested:
| JimKyle wrote: | | the From to contain "@example.it" (just like the three-rule solution) |
could do the trick because all incoming messages will be deleted a part from the ones sent to the first or second trusted address.
That's very bad with multiple mail accounts...
Maybe an additional option in ASS would help...an option to limit black rules to certain accounts only...I realize it's much complicated for developers, though....
| JimKyle wrote: |
Do you have the "friendly address" options set up to learn automatically? That might be what is forcing the wrong-learning situation... |
Yes, I have this option enabled. I'll try to set it off and see what happens. I'll let you know. In any case I think any messages who undergoes a black rule definition must always be classified and learnt as spam.
I'll try to disable the automatic friendly address learning option.
see you soon  |
|
| Back to top |
|
|
vetaltm
Author
Joined: 05 Feb 2006
Posts: 748
|
| Posted: Tue Sep 19, 2006 2:07 am Post subject: |
|
|
| paolo73an wrote: | Sorry for bothering you again but I've noticed 2 things I don't like much
1- with the combination white/black rules, I see in the log window that spam messages are classified as ham. Maybe the final result is good in the sense that the message is then deleted, but the black rule behaviour doesn't appear in the log and worst of all the spam message is classified as good
|
What rule is stated in Reason field of the corresponding log records? It seems that you have two plug-ins installed and that is the reason of strange behavior you described.
| paolo73an wrote: |
2- using the "not" syntax with the trusted address, makes all other messages be classified as spam.....
any further trick? |
I agree with Jim here. You can add a condition to the black rule for avoiding deleting the messages from other accounts. For example, the black rule for your case may look like this:
Not Header{To} =~ info@example\.it|support@example\.it
Not Header{CC} =~ info@example\.it|support@example\.it
Header{Received} =~ example\.it
The messages directed to info@example.it or support@example.it will be passed by this rule (and filtered then by other rules and methods if there are no white rules for them). All other messages sent to example.it will be deleted.
You must take into account some exceptions:
- The messages with one of the white addresses in BCC field instead of To or CC will be deleted. Make sure that nobody uses that method for sending you good emails or create additional white rules for such cases.
- If your mail server hosts several domains, then it is possible that the messages will have different domain name in Received header. You can check this by reviewing the sources of some message in TheBat (F9). Specify the correct domain(s) or the server IP address(es) in the last rule. Don't forget to quote dots in patterns, especially for IP addresses. E.g. the pattern for IP might look like this: 192\.168\.1\.1
Check the created rule in testing mode to be sure it works well. The incoming messages in testing mode will be filtered as usual, so it is not recommended to download the email during tuning the rules. |
|
| Back to top |
|
|
vetaltm
Author
Joined: 05 Feb 2006
Posts: 748
|
| Posted: Tue Sep 19, 2006 2:22 am Post subject: |
|
|
| JimKyle wrote: | I think that your first point reveals a bug in the Sniper, or maybe just a logical oversight in the program design. Perhaps there needs to be another option, similar to the automatic learning for friendly addresses, so that any message satisfying a black rule gets learned as spam. It's definitely not right for a message that's rejected by a rule be learned as ham!
|
The messages, recognized as spam, are never learned. I think that the first problem caused by some mistake in rules and another plug-in installed simultaneously with AntispamSniper. That is the only reason I see in case when the messages are classified as good according to log, but then deleted anyway. It is possible if the method of calculating the summary spam ratio is defined as Maximal. E.g. AntispamSniper says that the message is not spam (ratio equals to 0), the other plug-in says that it is spam (ratio is 60 or more). TheBat takes the maximum from two results and marks the message as spam. |
|
| Back to top |
|
|
vetaltm
Author
Joined: 05 Feb 2006
Posts: 748
|
| Posted: Tue Sep 19, 2006 2:41 am Post subject: |
|
|
| paolo73an wrote: |
| JimKyle wrote: |
.....
Your second point reveals a logic mistake on my part. Re-examining just what the two NOT lines would do shows that any message that isn't from one of the two accepted "example.it" addresses would be rejected. Possibly adding another line to the rule to require the From to contain "@example.it" (just like the three-rule solution) could overcome this and make it work as intended -- and it might also keep the rejected messages from being learned as ham.
..... |
I don't think what you say would work....
that's because I have multiple mail accounts and the black rules are applied to all, not only to the account related to @example.it....
In that way I don't think to insert the rule you suggested:
| JimKyle wrote: | | the From to contain "@example.it" (just like the three-rule solution) |
could do the trick because all incoming messages will be deleted a part from the ones sent to the first or second trusted address.
That's very bad with multiple mail accounts...
Maybe an additional option in ASS would help...an option to limit black rules to certain accounts only...I realize it's much complicated for developers, though....
|
I've provided a description of the working rule for your case above. The "trick" is that the black rule filters the messages, received from certain server. The other accounts are excluded automatically in that case, so there is no need in additional limits.
BTW, an additional option for linking the rules or other options to certain accounts is more complicated for users, than for developers  The configuration options are already not-so-easy to study. That is the only reason why the options are not linked to accounts yet and some other advanced things are hidden.
| paolo73an wrote: |
| JimKyle wrote: |
Do you have the "friendly address" options set up to learn automatically? That might be what is forcing the wrong-learning situation... |
Yes, I have this option enabled. I'll try to set it off and see what happens. I'll let you know. In any case I think any messages who undergoes a black rule definition must always be classified and learnt as spam.
I'll try to disable the automatic friendly address learning option.
see you soon |
You don't have to turn off that option if you are not sure that the rules are not working because of some record from friendly list. Check the log please, and look at the value of reason field out there. |
|
| Back to top |
|
|
paolo73an
Joined: 04 Sep 2006
Posts: 29
|
| Posted: Tue Sep 19, 2006 11:24 am Post subject: |
|
|
| vetaltm wrote: | I agree with Jim here. You can add a condition to the black rule for avoiding deleting the messages from other accounts. For example, the black rule for your case may look like this:
Not Header{To} =~ info@example\.it|support@example\.it
Not Header{CC} =~ info@example\.it|support@example\.it
Header{Received} =~ example\.it
The messages directed to info@example.it or support@example.it will be passed by this rule (and filtered then by other rules and methods if there are no white rules for them). All other messages sent to example.it will be deleted.
You must take into account some exceptions:
- The messages with one of the white addresses in BCC field instead of To or CC will be deleted. Make sure that nobody uses that method for sending you good emails or create additional white rules for such cases. |
I've looked in thebat! with F9 at the headers.
I've managed to bypass the cc or bcc problem vetaltm talked about by putting these records in one black rule I've created on my own taking care of your suggestions:
Header{Delivered-to} =~ @example.it
Not Header{Received} =~ (info|support|whatever)@example.it
Not Header{To} =~ (info|support|whatever)@example.it
Up to now it seems to work well, it rejects all malformed addresses except trusted ones.
Just what I wanted
I hope it will work in future.
By your experience do you think these rules have bugs for specific exceptions?
What about these rules? Do they look good to you?
bye
Paolo |
|
| Back to top |
|
|
vetaltm
Author
Joined: 05 Feb 2006
Posts: 748
|
| Posted: Thu Sep 21, 2006 8:14 pm Post subject: |
|
|
| paolo73an wrote: |
I've looked in thebat! with F9 at the headers.
I've managed to bypass the cc or bcc problem vetaltm talked about by putting these records in one black rule I've created on my own taking care of your suggestions:
Header{Delivered-to} =~ @example.it
Not Header{Received} =~ (info|support|whatever)@example.it
Not Header{To} =~ (info|support|whatever)@example.it
Up to now it seems to work well, it rejects all malformed addresses except trusted ones.
Just what I wanted
I hope it will work in future.
By your experience do you think these rules have bugs for specific exceptions?
What about these rules? Do they look good to you?
bye
Paolo |
I have two remarks:
1) If the destination address is specified in Delivered-to, then usually it is not referenced in Received headers as "Received: ... for smb@domain.com ...". And vice versa. In both cases that address is added by email server, when putting a message to some account. It means that the second condition can pass the spam messages with invalid addresses in To or CC, and a valid address in BCC.
2) You've omitted the condition for CC field, so you can lose the good messages with a valid address in CC. |
|
| Back to top |
|
|
paolo73an
Joined: 04 Sep 2006
Posts: 29
|
| Posted: Thu Sep 21, 2006 9:08 pm Post subject: |
|
|
| vetaltm wrote: | | paolo73an wrote: |
I've looked in thebat! with F9 at the headers.
I've managed to bypass the cc or bcc problem vetaltm talked about by putting these records in one black rule I've created on my own taking care of your suggestions:
Header{Delivered-to} =~ @example.it
Not Header{Received} =~ (info|support|whatever)@example.it
Not Header{To} =~ (info|support|whatever)@example.it
Up to now it seems to work well, it rejects all malformed addresses except trusted ones.
Just what I wanted
I hope it will work in future.
By your experience do you think these rules have bugs for specific exceptions?
What about these rules? Do they look good to you?
bye
Paolo |
I have two remarks:
1) If the destination address is specified in Delivered-to, then usually it is not referenced in Received headers as "Received: ... for smb@domain.com ...". And vice versa. In both cases that address is added by email server, when putting a message to some account. It means that the second condition can pass the spam messages with invalid addresses in To or CC, and a valid address in BCC.
2) You've omitted the condition for CC field, so you can lose the good messages with a valid address in CC. |
In my case,I've noticed the email server puts the address in the "Delivered-to" header if the message has a correct address with domain (@example.it) in the "To" or in the "Cc" field
Then I've noticed that messages sent through "Bcc" have addresses in the "Received" header
Then I've seen malformed address don't appear in "Received" header but only in the "To" field, so I block all messages in "To" header which not correspond to correct ones.
It works 100% in my case. It never missed a shot |
|
| Back to top |
|
|
|
FAQ
Search
Profile
Log in
Register
