Wizard IT Products

I'm seeing a lot of spam come through as HAM. I'm viewing this from the "Recent Log Entries" in the dashboard.

As an example:
drugaddictiontreatment@elevisionclearn.link
home-solar-panels@usasolarsun.party
hawaiivacationdeals@hiketaspental.webcam
my-snoring-solution@educingelephore.party

What I see with these is that they all come from TLDs that are very unlikely to have HAM mail. I'm sure my clients would prefer to cut their spam by 50% and take the chance of losing a legitimate email from a .party or .link. I think that's really quite unlikely, anyway.

Can I ban a TLD?

Hello j*z,

Thank you for your post and your question. At the moment it is not possible to blacklist entire TLDs. This was a decision made because of the inherent risk. These days though, with so many "dot anything" TLDs out there we may need to revisit this decision.

In the meantime though what we suggest doing is that you use the log search tool to find the IP addresses that these messages are coming from and then check the IP addresses using the BMS checker (http://www.linuxmagic.com/products/bms/). If you start to notice a pattern and a large majority of these IP addresses are on a specific list, we might suggest experimenting and enabling that list.

Feel free to post up some log search samples here as well (we recommend you obfuscate the recipient address) and we will be happy to provide some recommendations.

Thanks again for your question!
-- MagicSpam Support Team --

I grabbed about 50 HAM labeled emails from a client's account. I doubt any of these are HAM although I changed a few of the domains to read "a-ham-domain" in case they were HAM. As far as IPs go, many are similar. If I can wildcard the final few numbers I might be able to get rid of some. But in the long term it seems a losing proposition.

The forum limits URLs to just 4. And I don't see a way to make an attachment instead. How do I get the log to you? Here's a few:

HAM
no
208.185.3.93
hutcp4vp.o90. science
03ace18c.o90. science
brianchambers@o90. science
recipient email address
Wednesday, Jul 08 2015 @ 12:46:10 AM
HAM
no
208.185.3.94
yc7aaxm0.oe4. science
03ace18d.oe4. science
reversediabetes@oe4. science
recipient email address
Wednesday, Jul 08 2015 @ 1:16:06 AM
HAM
no
208.185.3.95
ki2bmc.sye. science
03ace18e.sye. science
enddayssurvival@sye. science
recipient email address
Wednesday, Jul 08 2015 @ 4:03:29 AM
HAM
no
208.185.3.96
i6dxw1.zoh. science
03ace18f.zoh. science
oceansalive@zoh. science
recipient email address
Wednesday, Jul 08 2015 @ 4:15:40 AM
HAM
no
66.248.215.191
ybmd143v6.infobusinesssubscription. party
ybmd143v6.infobusinesssubscription. party
bloomberg-business-week@infobusinesssubscription. party
recipient email address

of the 50 marked as HAM, I'd say 50 were spam. I pulled a few that I couldn't say for sure.

Here's the rest.

http://zoledesign.com/MagicSpamLogs.htm

Hello j*z,

Thank you for collecting that information for us! For larger logs in the future, you are welcome to email them to us at support@magicspam.com.

What we did in this case is we checked the IP address against our BMS look-up tool to see if the IP addresses were listed on any reputation lists available in MagicSpam.
http://www.linuxmagic.com/products/bms/lookup

We could see that all the IP addresses were on MIPSpace-all or MIPSpace-poor! As MIPSpace-poor is the lighter of these two lists, we might recommend starting off by trying MIPSpace-poor and seeing how much of a difference this makes on the situation.

We get that feeling that this list will benefit you greatly! Please let us know if you have any other questions though,
-- MagicSpam Support Team --

Thanks for the suggestion about MIPS-space poor list. That's enabled an enormous reduction in spam. I did find that some mailing-list (bulk) mail that wasn't spam per se would end up getting caught in the filter. For my needs this seems to work fine in that I can whitelist IPs and email addresses. Despite your recommendation to not whitelist an email with a wildcard, I'm finding myself doing that at times. Not always possible to know all the possible email addresses from a particular sender. I found that the newsletter service Constant Contact provides a listing of all IPs used to send their mailings. Most others don't however.

So far I'm very happy with MagicSpam! Thanks for the excellent support.

I would like to put my 2 cents in also, I have already asked this, but please let us decide how to block these types of things.

I want to block ALL .top domain. I don't need nor want anything if someone is using this. I have been getting a lot of spam from them lately and it drives me crazy that you guys don't allow wildcarding on black lists.

Please allow the system admins the ability to do wildcards on this type of stuff

New user here, wanting to add my thoughts on this topic.

In my old setup (qmail with qmail-scanner and spamdyke) I had an rdns blacklist/whitelist as well as a sender/recipient/IP whitelist/blacklist.

In this case, the rnds I'm talking about is the unconfirmed/unverified rdns - i.e. the result of looking up the PTR record for the connecting IP and not anything more sophisticated.

Using the rdns blacklist, I was able to block large amounts of unwanted commercial mail (from certain ESPs/bulk mailers) as well as spam from compromised servers and individual trojaned PC, with what I considered to be 0 possibility of false positives.

For example, adding .vn blocked a huge chunk of spam as the rdns of the senders ended in .vn but the visible "from" address had nothing to do with that ccTLD. There were too many different IPs to block easily.

But it wasn't just TLDs/ccTLDs that we needed to block on the old system. We also needed to block deeper level rdns like .speedy.net.pe and .tellcom.com.tr

Again this is the rDNS - the visible "from" address has something totally different in it.

I found being able to block these extremely useful, and allowed me to target very narrowly.
While I appreciate that the sending IPs could have been on a block list of some description somewhere, I'm not keen on adding too many such lists, as the possibility of false positives increases with each one.

I also appreciate that in the case of the .vn issue, I could have used one of the country code rbls that targets IPs in a certain country. And while this would work in the case of this ccTLD, it would not work with one of the new "descriptive" TLDs

When looking at setting up such whitelist/blacklists in Postfix (with or without Plesk) I did note how strongly the documentation emphasised that *whitelisting* based on **unconfirmed/unverified** rdns was a bad thing, as in theory you can set a PTR to anything you want if you have control over it.

So I do see how there can be a bit of a minefield here.