SpamAssassin marks my email with reason BAYES_99 , which means the email is 99% ~ 100% spam email. What is the mechanism of SpamAssassin to detect this rule (by keyword?), and how can I avoid hitting this rule?
I found this because I was using SendGrid for transactional mail, and sendgrid was sending MY mail from a server that had been blackholed for sending SOMEONE ELSE'S spam. Because the IP was blackholed, my emails were marked spam. To diagnose:
You can see if your domain or IP has been blacklisted here: https://mxtoolbox.com/blacklists.aspx
The fix was to switch to a different email transport provider.
BAYES_99 is a statistical component of SpamAssasin. It is using some sort/variation of Naive Bayes which has (to keep it simple) some sort of probability saying that some word/token is likely to be spam or not to be spam.
In "math" these could be expressed like this:
P(Class_Spam | Email)
P(NotClass_Spam | Email)
Transformations lead to e.g. this equation:
However there a lots of different representations of bayes classifiers. With different optimizations and statistical models.
You may disable it via spamassasin configuration. This question is not well placed on stackoverflow. Superuser would be the better fit though.
Related
I faced with a such question for which can not find an answer in google. For example, I have a company which provides some services for customers. And for new users I have a promo/discounts. As we know there are a lot of websites which provide fake number for receiving sms for registration. I need a useful solution to prevent registration with such numbers. I want to check if this number is real or not and allow registration only if real. What is your suggestion/solution ? What would you do or maybe already did something for escaping a such problems.
Note: Maybe Some tags are not relevant to this issue, so please inform me and I will remove this tag. Or vice verse, if you have any suggestions related tags please let me know I will add this tag.
Thank you in advance.
Usually what you do is you take the number/email and you send it to a service most likely through an API. There is rarely any inhouse software that does this functionality!
Here are a few services, I have used & worked with etumos before, not bad but it comes with a price!
https://etumos.com/products/etumos-verify/
https://numverify.com/documentation
For numverify, it is free to an extent. Try it out & see if it works with your solution.
It supports Carrier Detection
While phone numbers help businesses identify and legitimize customers, some numbers are very easy to retrieve from certain carriers. For exmaple, anyone can quickly register multiple phone numbers from a free online provider, making it easy to create fake profiles.
To address this risk, the numverify API will return a separate carrier object containing the name of the carrier the requested phone number is registered with. This way businesses can require additional identity authentication for carriers associated with higher fraud instances.
Send an SMS to the number, ask a question that a human can answer better than a bot and request a response.
This is simple question for those who know.
I have Google API registered access and as part of it
I was given few email addresses (#developer.gserviceaccount.com),
One per each type of access.
It seems that the main purpose of those email addresses, is to be a distinguishing ids.
My question is if its possible to use those email addresses as real mailboxes?
No, they are not destined to be used as email addresses, think of them more as user_id's for different purposes.
Here you can see an example os the #developer.gserviceaccount.com
I guess I'm a bit late for this answer but I am currently facing some issues with this subject so I think it might be useful to someone.
So right now my only spam protection is going to be to check all incoming messages against this table, http://www.stopforumspam.com/downloads/, that I have imported into my database, and if the IP is found, their message will not be posted.
We don't really want to hinder usability by having one of those "Type what you see..." or a sort of e-mail confirm system similar to Craigs List.
Will this IP check be enough to get rid of (most) spam comments, or should I really look into adding something else. Maybe there is some free plugin that I haven't found that doesn't hinder usability and will help us out more?
Thanks!
There you go :) http://akismet.com/
There's an API, you send them the comment body and they reply if it's spam or not. This is (maybe the best) spam hunting service, they have large word databases and good self-learning filters.
Additionally, it's free for personal use. I don't know how much it costs for business.
I'm in no way affiliated with them, I just found it by chance a couple of years ago.
akismet.com offers a quality service that will protect your site. Depending on the nature of your site there may be a fee. If your site is a personal blog they have a "WHAT IS AKISMET WORTH TO YOU?" plan where you can choose to pay $0. They would prefer that you pay $3 to $5 per month.
There's a reason captchas ("type what you see..." things) and email confirmation lists exist - there's always someone attempting to circumvent your site's security for personal gain. In all likelihood this will extend beyond spam, as well.
Just keep in mind that you're putting your trust in any external solution that you go with (which is why things like in-application email confirmations and captchas have gotten popular, considering they're not too difficult to implement and you have full control over them).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
what i have until now:
session on server side
unique id (md5) of computer created by Request.ServerVariables("HTTP_USER_AGENT") & REMOTE_HOST and saved on the database
but what else can i do in this case? users continue to share their login details :(
This is a problem in almost any line of work: from software, where someone can simply copy the program, to simple ticketing, and having an individual walk past the ticketing desk. (I worked in a ticket selling position, and we did have individuals walk in without paying.) This is largely a social problem, not a computing one, and it's been my experience that trying to fix social problems (people) with computers is largely futile. Here is a culmination of what I've heard on this topic, and the two categories the advice tends to fall into:
Try to control the problem.
Try to somehow identify and control the unscrupulous users of the system. This can be DRM for software, or a security guard in the example of the ticketing desk. This is essentially what you're trying now.
A problem I see with your current method is it doesn't support multiple browsers. I routinely browse from multiple browsers, and from multiple websites. If this is your method for identifying theft of your service, are you sure you're not seeing false positives?
If you do try to control the problem, the best thing I've heard is to make sure you don't affect the users legitimately using the system. Causing pain to a legitimate user by either making him install DRM software on his machine, or by requiring him to take off his shoes to get on a plane, only causes him trouble and degrades the apparent quality of your service in his eyes. Try to find ways to identify troublesome users without affecting the normal crowd: selecting blacklisting (banning) of IP addresses might be effective in the case of a web service. (Wikipedia controls spammers and malicious editors this way, and some people have controlled spam email this way.)
Now, the other line of reasoning:
Ignore the problem.
This stems from the "don't get in the user's way" ideals. Make your service as good as it can be for the user, and offer him a high quality service that he won't mind parting with his cash. In other words, make it worth his money. This depends on enough people being honest that you're still profitable, of course. Some argue that those who steal a service often wouldn't have paid for it anyways.
In reality, some mix of the two is probably the most effective measure.
Number two doesn't work. I login from at least five different devices. You definitely do not want to couple yourself to the hard- and software upgrade cycle of your customers
Get an cell phone number of user and send SMS with one-time password each time he tries to login. Email wouldn't work because it is too easy to share.
But you can see a great decrease in your user count: this thing is REALLY annoying.
The way I prevent users from sharing account information is by prevent multiple logins from one location. So if the user logs in, it will log out all other sessions.
This is relatively easy to do. Associate to each user in the database a field like session_key that is randomly generated on login. Store that session_key in the database AND in a cookie in the users browser, and check that the session keys match. If not, log the user out. Whenever someone else logs in, it generates a new session key, thus inactivating all previous sessions and logs out the user. You can also try keeping track of other information as well, such as the users IP address, etc associated with the session. It's not 100% foolproof, but it prevents most users from sharing accounts.
Log the IP addresses, times and usernames in a database table. Check the database for users that are active from more than one IP on the site, and ban those users.
Or, stop users from logging into an account if there is a session already on the server for that user.
There is no way to prevent this. You can only make it more difficult - But you should consider the downside: Legitimate users get caught in the crossfire. If I were you, I'd simply tackle the source of the problem - The reason you don't want people to share logins - And fix that instead. Make an incentive not to do it. Remove advantages for doing it.
The only way to stop the users from sharing something is to make that something non-shareable (at least not with some serious hacking). But this involves hardware which can be not appropriate for your project. I am talking about hardware cryptotokens, which hold private keys and don't let one copy them. If you give your user such token with the private key inside, the user can pass the token itself to other person, but he can't copy it.
That's simple. Use the 10 to 15 favourite questions and their answers during registration processes. Ask randomly one of them during each login.
now i think it is a combination of several factors if not all that can work
lower the subscription costs
prevent multiple sessions at the same time
use two factor auth
if app disable screen shots...make too much content on single pages to make it tiresome for someone to scroll down taking screen shots..disable screen recording if possible.....offcose by not giving any permissions
i think considering fingerprint scanning and face recognition hand in hand with device ids can work
lastly consider loading your website in a webview based app for android users
I assume it's bots, or something like them. We have forums on our website and daily we get 1000's of attempts to post spam. These never actually make it into the database, usually by throwing a ViewState or EventValidation exception. I'm not sure if I should even really be concerned. I'd really like to do something about these bots. Not only are they wasting our resources but it's more than a little annoying trying to sift through all these errors to find the real errors. Any suggestions?
It sounds like this isn't a content problem. Users don't see the spam, because the vast majority of the submissions are somehow mis-formatted. You've got a couple of options, depending on the control you have over your software:
If you wrote the forum software, or are able/comfortable with modifying it, you could catch the most common exceptions that these broken submissions throw. (It sounds like you've already identified those exceptions.) You could write those exceptions to a different "spam log" or some such, which would allow you to do stats and reporting down the road.
Using either the data from your spam log, or maybe even what you have currently logging, you could identify IPs or ranges that often send these bad submissions and block them at your firewall. If this is realy spamming, though, chances are that they have ways to get around it, since that's a pretty basic spam-blocking strategy.
It's also possible that this isn't spam, but instead it's a bad browser. If you could add User-Agent information to the exception/spam logs, you might be able to trace that. You might get lucky and it might turn out that fixing your forms for IE5Mac or Mini Opera or something like that would not only prevent these exceptions but also bump your visitor numbers.
Unless these submissions are making a measurable impact on the performance of your site, I don't think there's going much use in doing a lot more than that. Adding CAPTCHAs wouldn't prevent spam from being submitted, just from being successfully submitted (which it doesn't sound like is a problem right now). The only thing that's worth your time at this point is breaking the bad submissions into a separate log.
I believe CAPCHA was designed to fix this problem.
Best solution depends on the popularity (number of users) on your forum.
Most forum software have plug-ins for Captcha and related technologies. This is what you want for a large site. For a small site you can cheat by simply adding some random question to the submission form like "Are you human?" If they don't type "yes" in the input box they don't pass your (Turing?) test. Most spammers don't actually visit your site, they simply run scripts looking for known forum software or obvious comment forms.
In response to your last comment you can't stop an actual human spamming your site (even denying links is not enough). You certainly can't stop anyone sending you data without turning off your website. You should simply have moderators to remove any spam that gets through your captcha.
You could look at your webserver's log files and see what type of 'User Agent' those connections are coming from.
Browsers such as IE/Firefox have a User Agent signature of something along the lines of 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)'
The bots will likely have a (few) specific User Agent signature(s), you could add these to a black list in your server's configuration files so that your server will just ignore requests from them.
Also you should take a minute to read through
http://www.kloth.net/internet/bottrap.php