Email filtering

[virtualmike]

Yes, you should add the wildcard if you want to filter all addresses from that domain. Otherwise, only email from a sender whose address literally is "@mail.ru" will be filtered.

[boss]

So the Russian spam continues. 90% of the spam on my blacklist is blocked. Why does that 10% get through? If I blacklist *@mail.ru why would a few of these get through to my inbox?

Perhaps more importantly, is it possible to block email from ANY .ru domain? They have more @spamnames.ru than I have patience.


Thanks again

[tjj]

You could set SpamAssassin to only allow english local e-mail through as well as adding *@*.ru to the blacklist. Here is a link to the tools where you can set the allowed locals: https://members.sonic.net/email/spam/spamassassin/

[markf]

I have to say this and I have been with sonic for a very long time. Sonic, your tools or lack of control for the end user for terms used to filter on is shit. I have brought this up so many times in the last few years only to hear excuse after excuse instead of solving the problem.

WTF do you have user tools and then tell me to use procmail? The fact is that with two words in the "TO" field I can block almost all of my spam and if you rejected email without a "TO" field it would stop over 90% of all the spam.

All I hear is use procmail or SA isn't set up like that. The fact is that almost all the spam I get is sent to "undisclosed recipient" or some variation or has no "TO" field at all. Instead of allowing your users to reject and delete 90% of all their spam with a couple of rules you tell them to go FO and use procmail and provide excuses as to why they can't filter on this.

The fact is that the end user should be able to filter with any term they so desire. But all I hear is that is an invalid character and so all spammers have to do is to continue to use "invalid" characters and unless you use procmail you can't block their spam at sonic.

[markf]

Also, you could filter as follows with SA for , RU. I believe SA is still recognizing [*] as a wildcard.

.ru/ anywhere

You could also try *@*.ru which should only block email addresses from a .ru

So the Russian spam continues. 90% of the spam on my blacklist is blocked. Why does that 10% get through? If I blacklist *@mail.ru why would a few of these get through to my inbox?

Perhaps more importantly, is it possible to block email from ANY .ru domain? They have more @spamnames.ru than I have patience.


Thanks again

[boss]

Mark, thanks for the link to the spam sites. Interesting reading.
Can someone help me figure out why I get the spam to my inbox and then, later, I get the email again in my grey folder. It's like spam assassin is only catching the spam after it goes to my inbox.

[kbenson]

I have to say this and I have been with sonic for a very long time. Sonic, your tools or lack of control for the end user for terms used to filter on is shit. I have brought this up so many times in the last few years only to hear excuse after excuse instead of solving the problem.

Mark, I know you're frustrated, you've been fighting spam and for different mitigation controls for years. Unfortunately the reality is that adding a new tool is not always a simple technical issue. Unfortunately, there's other concerns such as support for that tool. Our technical support department would need to support any new tool we created (regardless of whether it's marked as unsupported, support will still be expected), and that adds an extra burden.

As it is, the capability is there, we just don't throw a shiny interface on top of it and offer support. For some that's not ideal, but it is the trade-off we've accepted up to now.

P.S. I'm not stating this is the one reason there is no procmail tool, nor even that it's an important reason of many possible, just that it's one aspect that you completely ignore in your post.

[markf]

I have to say this and I have been with sonic for a very long time. Sonic, your tools or lack of control for the end user for terms used to filter on is shit. I have brought this up so many times in the last few years only to hear excuse after excuse instead of solving the problem.

Mark, I know you're frustrated, you've been fighting spam and for different mitigation controls for years. Unfortunately the reality is that adding a new tool is not always a simple technical issue. Unfortunately, there's other concerns such as support for that tool. Our technical support department would need to support any new tool we created (regardless of whether it's marked as unsupported, support will still be expected), and that adds an extra burden.

Not a "tool" of sonic so sonic does not support it. The other and more immedaite issue is the fact that a tool that is essentially unusable is not a tool but a hinderence. It is the same or similar to giving somebody a battery operated toy and no batteries.

As it is, the capability is there, we just don't throw a shiny interface on top of it and offer support. For some that's not ideal, but it is the trade-off we've accepted up to now.

P.S. I'm not stating this is the one reason there is no procmail tool, nor even that it's an important reason of many possible, just that it's one aspect that you completely ignore in your post.

Just so you know, procmail is available to people to use on sonic so you will have to be a bit more specific as to what it is I "ignored".

[kbenson]

Not a "tool" of sonic so sonic does not support it. The other and more immedaite issue is the fact that a tool that is essentially unusable is not a tool but a hinderence. It is the same or similar to giving somebody a battery operated toy and no batteries.

Maybe I misread your post slightly. I took it as an indictment that we don't support filtering at the level procmail supports. Upon review, that may not have been your intention.

Just so you know, procmail is available to people to use on sonic so you will have to be a bit more specific as to what it is I "ignored".

Sorry, by tool I meant a member tool available to Sonic.net customers (I'm well aware procmail is available, which is what I meant by saying the capability is there). I'm of the opinion that advanced tools with advanced capabilities require more support, and stating that more features need to be added to the email filtering capabilities users have access to without addressing that in any way is ignoring some facets of the problem.

[markf]

I know what tools are online and available through sonic. I have been with sonic since 1996 and see the invalid character issue as one spammers can easily exploit and currently do exploit so much so that this two issues account for almost all of my spam. I suspect it is the same for most email users.

The fix is not a difficult one. Few use "undisclosed recipients" any longer. There is freely available software to handle mailing lists so there really is no excuse to use this anymore except comfort. I see no reason that any software should not have a "TO" field and see no reason to accept email from servers that have this missing from the header.

If the end users could actually say what he/she wanted filtered then this would be moot. The fact is that all spammers have to do is add a character that SA does not recognize to get their spam through filters. To block the same percentage of spam would require me to create procmail filters for the "TO" field or set up a massive number of character strings to filter on, for the body, from, to and subject fields.

It doesn't make sense to expend that time and effort when you can get the same results from rejecting all email sent without a "TO" field and all email sent to "undisclosed recipients".

If somebody is worried about a friend that still uses "undisclosed recipients", whitelist them in the from field. It you are worried about losing stuff where you are cc'ed, whitelist the email addresses usually associated with people that email is sent to where you are cc'ed.

There are common sense solutions out here.