Collateral effects on banned IP on hMailServer? - hmail-server

In hMailServer:
I want to know what happens if I ban one or more IP addresses or domains.
Of course, the emails will not be accepted by hMailServer, but is the banned IP address marked as SPAM source?
Is there any other (global) impact on the source that is banned?
Thanks.

Again, I found my answer alone, asking this directly on hMailServer forum.
The answer is here: http://www.hmailserver.com/forum/viewtopic.php?f=7&t=20364&p=123981#p123981

Related

Do subdomains protect a domain's reputation when sending emails? [closed]

Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 months ago.
The community reviewed whether to reopen this question 5 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm working on an application that is meant to distribute emails by the thousands. We've started interfacing with Mandrill to accomplish this.
So my coworker suggests that we use a subdomain to send all of theses emails out, so as to protect our top-level domain's reputation. We started squabbling about this because, as I argued, why would a simple subdomain protect our TLD, especially if they both resolve to the same IP address? If marketing.example.com is sending thousands of emails, aren't spam filters smart enough to know that they really originate from example.com?
So to clarify:
We're currently using Mandrill to distribute mail
We use DKIM to verify that the domain example.com is the originator of the message
Right now, we're only using one server to handle all this (plus Mandrill)
So how would switching the sender to marketing.example.com (with matching DKIM) help protect our TLD's reputation as a non-spammer? I don't understand, yet I've read articles to this effect, and he argues fervently that it's the right thing to do, yet no one can tell me how it works. I understand it from an organizational standpoint, but I don't understand how that protects our domain, unless spam filters really judge rep by the subdomain.
Can someone please help me piece this together?
Edit:
Here are some articles for reference:
Quora Question
LuxSci Blog
Mail Chimp Delivery - See page 11
Using a sub-domain will mitigate against the potential damage that could be done to your reputation by a miscreant user sending a campaign to a purchased list and using sub domains is considered best practice as per what you have read online.
In the first instance the big mailbox providers are not expecting to treat all mail sent from a domain in the same way. Google will want to classify your marketing messsages differently to notifications/transactional mail. One way to assist the mailbox providers in that task is to utilise sub-domains for different message types.
It is not about attempting to evade the spam filters, it is about providing meaningful and useful information through what most would consider proper utilization of rDNS. You are only mitigating because even if the BL operator or mailbox provider do assign separate reputations to each subdomain if sub-domains are being listed constantly then you do run the very real risk of having your TLD listed.
Spamhaus who operate one of the most widely used blacklists said this on the subject "It's a good way to convey in rDNS what is really happening within your network in terms of different customers sending different mailstreams. The risk is that "maindomain.com" may get filtered if too many subdomains look bad, but that needs to be a risk you accept and manage by maintaining the reputation of all subdomains."

Allowing one vote per computer (not IP, not logged in user)

I have a site where i want to allow a 5 star rating on various things. However, like many other people asking questions on SO, i only want to allow one vote per person.
At first i was planning on logging the IP address when a vote happens and just scan to see if the current IP had voted before or not which would work great.
But then i realized a problem, the site is designed for college students at one particular school. A couple issues with this if i understand IP correctly:
People using school computers/connected to the school wifi will have the same IP(maybe a handful, but not unique to each computer)
Many people live in houses of 4-8 people, where they would all share the same IP(assuming they are on the same network)
How could i detect unique votes without using IP addresses or having a user login? Is there any other way to do something like this?
Or maybe i am misunderstanding how IP addresses work and i can still use that - hopefully this is the case.
Thanks
You can do this any way you want. There is no "one right way".
On the extreme end, you can have users submit a blood sample when they request an account. You can then check new blood samples against your database. This could result in people submitting family member's blood samples. If that's a concern, you may wish to have them sign a contract, notarized most likely, stating that they have submitted their own blood sample.
You could also have them personally register at your office. You could, for example, collect fingerprints and compare them to your database.
IP addresses are not very useful for this purpose. Some people have access to dozens of IP addresses and in some cases many people share a single IP address.
You could only give a vote to users who have made a large number of intelligent posts to a forum. That would at least cut down on the ease with which people can create voting accounts.
I am not sure if it can be implemented in your application but try logging for unique MAC address instead of unique IP address. MAC address are universally unique for each network controller and usually PC just has one.

Prevent MediaWiki from being spammed

My MediaWiki site is currently under the spammers attack. I get around 10 spam pages registered daily.
What I've I already done:
Only users with confirmed emails can create/edit pages.
ReCAPTCHA widget.
Captcha displayed on the actions:
'edit' - triggered on every attempted page save
'create' - triggered on page creation
'addurl' - triggered on a page save that would add one or more URLs to the page
'createaccount' - triggered on creation of a new account
Proxy blocker
SpamBlacklist
What else can I do to stop the spam?
It's counter-intuitive, but I have found this combination very effective:
Disable new signups or if you think that is too extreme, install SecurePages
Install SimpleAntiSpam
Install SpamBlacklist and TitleBlacklist
Allow anonymous edits
Always block the IP addresses that spam is posted from
Install User Merge and Delete and use that to clear out the existing spammer accounts.
#1 is the most important step. It's easy for spammers to create throwaway accounts.
A CAPTCHA makes only a small difference, not worth the extra bandwidth cost for the images.
The hundreds of throwaway accounts are almost as big a problem as the spam postings.
#2 reduces the volume of spam by at least 1/3.
The only robots that get past SimpleAntiSpam are those specially designed for MediaWiki, not the ones that fill in all textareas in every web page everywhere.
Similarly if your site has SSL, SecurePages (or its predecessor HttpsLogin) thwarts some bots that don't have SSL support.
#3 will stop you getting the same spam posting (or variants of it) repeatedly. If you update the blacklist regularly that should reduce the volume of spam by another 10-20%.
And remember the spammers will run out of paying customers (you eliminate one for every domain you block links to) long before they run out of public proxies/zombies to post from.
#4 does not increase the volume of spam as much as you might expect. There's a popular MediaWiki-spamming bot that never attempts to post anonymously - it gives up when it cannot find the "create account" link.
And if you don't do this, you don't have a wiki anymore (you just have a static website using MediaWiki as a CMS.)
There is a small bonus - it makes it easier to find (and block) the spammers' IP addresses. Of course you can get the IP addresses using CheckUser or by reading the database directly, but it's much easier when the IP address is in plain sight.
#5 is the least effective measure, but it's still worth doing. Spammers do re-use IP addresses. They may be cheap but they are not infinite, and sometimes you will catch one of those runaway robots that posts a spam page every 5 minutes.
#6 doesn't prevent spam, but it allows you to clean up your user list page once you have other anti-spam measures in place.
Maybe you can check IPs used for spamming?
Or use special questions instead of standard CAPTCHA? (for example, one of NetHack (roguelike) related sites is asking for symbol of ring/spellbok/potion - trivial for NetHack players, impossible for bots/hired spam solvers).
I used to have a HUGE problem with spam attacks on my wiki. I used to have to go through the wiki everyday and manually delete spam posts and then block the addresses but this was a never-ending battle. Restricting editing to registered users didn't help as the spammers just got tyhemselves registered. So I finally had to shut the site down.
I started a new wiki where I have managed to block all spam.
My wiki is for a particular professional group so what I did was add in a username/password that had to be used to access the wiki directory. The username was displayed on my home page so no secrets there. BUT the password was the answer to a cryptic question selected carefully so the answer was easy for people in my professional group to answer but very hard for a spammer and certainly not something a a bot could work out. The question was selected so the answer could not be found by a Google search on any of the words - I had a mis-spelling and a non-standard abbrevaiation in the question. As it turned out about 1% of my target audience (mostly non-English speakers) found the question troo cryptic so the alternative was for them to contact me by email using a professional organisation email address (not gmail or hotmail). The answer was one word all in lowercase.
I thought I would have to change the password every so often BUT after several years there has been not a single spam message posted so I've just left the same question.

is it possible to check if someone is trying to vote from the same computer

From my knowledge the answer to this question is no, but i might be missing something. There are some polling sites which claim that voting from the same computer is forbidden and will result in a ban. How can they detect that? A cheater may use routable IPs, different operating systems, different browsers, proxies etc.
Cookies, and assumption that the multi-account cheater will sooner or later forget to clear cookies or use wrong browser and they will got him.
To sum up all that I could find: the answer is no. You can't be 100% sure that the user is trying to vote from the same computer. Advanced solutions to prevent this is to check the IP and, using maybe a java applet, find out the user's computer account name, and maybe set a limit to the number of votes coming from that IP anyway. Also, a human should be screening the results anyway and see how many of those IPs belong to institutions or college campus blocks, and make decisions to keep those votes or not, if you really want to be thorough. Gathering as much information about the voter as you can is useful (OS, browser, referrer, plug-ins etc.) Other tricks involve checking if the voter has visited several resources from your server first before validating his vote and not giving negative feedback when this fails to make fraud attempts less likely.

Do we really need email confirmation?

I've gotten into a habit of using the standard register->send activation email->activate account process for every site that supports user authentication and free registration without questioning if I really need this.
What are your thoughts on this? If I have captcha on the registration form is the email confirmation process really necessary?
EDIT:
OK, so the general consensus seems to be that by getting the users to confirm the email they entered I'll keep them away from putting someone else's email in there.
What about when I let users edit their profile/settings and they enter another email?
If I need to keep them away from entering other people's addresses then I'd need to confirm that email address (by temporarily deactivating their accoun)t every time they change it.
Captcha+activation prevents bots AND spoofed people
Well basically it is since each part prevents one problematic scenario:
Captcha prevents (if you use strong captcha like reCaptcha) bots from registering new users
Email activation prevents people from registering other people (by their email address)
I guess this is a valid everyday pattern for registration that's widely acknowledged by IT community.
EDIT
Yes. When you want to prevent users from changing their email address, you'd have to repeat email activation procedure to make it robust.
But you don't have to deactivate their account while doing it. All you have to do is having a pending email-change email activation active. If it gets activated, you change email address at that point (not when they change it), otherwise the old one is still used.
If you don't confirm an e-mail, you're supposing that the user registering that service owns that email account. How can you start sending a lot of system e-mails, reset passwords and etc to a person that has nothing to do with your system? I would be really pissed of if it was my e-mail.
Another scenario: what if the register mispelled his e-mail when registering? Suppose he doesn't check his "account settins" in your application, doesn't change his email, and needs to reset his password. If the e-mail is registered in a wrong way, it's your fault for not checking it before.
Of course, I'm just saying this to services that would REALLY demand an account to be created. Avoid the login barrier when possible, or use openid when your service isn't so critical.
You should give serious consideration to supporting OpenID. http://openid.net/get-an-openid/what-is-openid/
The key benefit for OpenID is that it reduces the complexity for your user. There is no reason to force people to remember login credentials for hundreds of sites when a viable alternative exists. There is no worldwide netizen database - and there likely never will be - but OpenID simplifies the situation greatly.
I know that as a user I found the registration process for Stack Overflow to be painless and easy. I wish more sites used OpenID.
It's the lowest-level attempt at identity validation. It encourages users to re-use the same account when they return (by having a common, shared identifier you and they can use to reconnect), and it prevents impersonation, because it requires access to the claimed identity as proof.
It's not perfect, but something by definition works infinitely better than nothing.
If identity doesn't matter on your site (e.g. your service is throwaway after each use) then you don't need email activation. Otherwise, you probably want it.
On my site, I let users sign-up and do everything non-public until they confirm their email address. Because I run a gaming website, it means users can earn medals, post scores, just not post in the forum or post comments in the blog until they verify their email address.
I find it works pretty well. I have 16,000 registered users.
I find it both unnecessary and annoying. If I can, I avoid doing this.
However, I do do this if 1) email will be sent by the program, so I can test if the email address is valid, or 2) this is a very large, public-facing website, in which case I want to filter out as many potential problems as possible.
For most basic sites, I don't bother with either. Both email activation and captcha are relatively easy for dedicated spammers to bypass and overcome and do little but cause an annoyance to most of the users, driving away at least a certain percentage who might have otherwise signed up. I've found in my experience, focusing more on spam filters for member posted content has a better ROI overall.
For sites with more serious content, you'll typically have more serious users. In cases like that, I'll throw everything I've reasonably got available at it to counter the spam.
I find it useful when an email is sent for confirmation. This makes sure that I am the one who has registered with that email address.
Even with captcha you can register someone else email address although he may or may not approve that confirmation.
You only seem to need e-mail confirmation to confirm identity, not to send useful content by e-mail. But e-mail confirmation is only one means to an end. You may consider others, preferablly less intrusive ones.
Generally you can check something that
you are (e.g. fingerprint, iris scan)
you have (e.g. token, creditcard, key, access to an e-mail account)
you know (e.g. PIN, password, your mom's weight, name of your favorite deceased pet, the optimistic length of your most private bodyparts measured in inches)
Also, you can delegate the check to others; the creditcard company, phone company, someone's friends.
Example: GoogleMail could not ask
for a confirmation e-mail address
upon creation of your GMail account.
Instead, the early adopters had a limited supply of
"invites" to share with friends.
So - unless you actually need me to receive information you'd e-mail, which I generally hate anyway - you might be inclined to resort to more creative/fun means.