Range of IPs in Mail rules

I'm not sure how you'd do that with Mail rules, but you should be able to block IP ranges in your router's settings. Of course, that means they won't be blocked if you connect to the internet away from home.

Yes very clear. But I don't think the mail rules work like a Routers Firewall system where you can specify xxx.xxx.xxx.xxx/24 (or whatever to block a full range of IPs). You could give that a try and see what happens.

Blocking those IPs on a router, which you need a Good router to be able to do that, would not stop that mail from showing up. As I think you may know your mail is coming from YOUR ISP/Mail provider not directly from those IPs.

Shootist007 wrote:

As I think you may know your mail is coming from YOUR ISP/Mail provider not directly from those IPs.

Good point. Kinda forgot about that!

I have the same problem and have been using the following workaround. Rather than block a range of IP addresses, I just block the entire subnet that is responsible for malicious spam and phishing messages.

I realize that this is like killing a spider with a shotgun, but the subnet administrators appear to be complicit in these acts and have refused my attempts to get them to curtail abuse of their networks for these illicit purposes.

So, like you, I've enabled doing boolean filters on any "RECEIVED" fields in the message header. Then, I have a list of conditions and when "ANY" of them are met, it bounces the email and deletes it. The rule is titled "Bounce SPAM" and each condition is of the form: If "Received" contains the string, "[89.39." then execute applescript "bounce" and move the message to "Trash".

I create a different entry for each offending subnet. Not as precise as what you wanted to do, but it does allow you to kill all messages from any IP address inside of that subnet. If you want to be a little more surgical, you could add the third field in the offending IP address, like so, "[89.39.140." as the search string. For the most malicious of SPAM, I've found that blocking at the second indenture of the IP address works fine (the subnet listed in the example is assigned to Romania, and I'm not worried about unintended collateral damage by blocking ALL romanian email).

What would be more effective is if APPLE would allow individual users to set filter/blocking criteria in the iCloud settings based on strings in the "RECEIVED" header fields. That way, the mail could be blocked at the server, instead of on your client, and would be a coveted capability for IOS mobile devices who lack the sophisticated filtering schema of the Apple Mail.app under OSX. For some reason, virtually all email server administrators do not want clients to be able to program blocks at the webmail service level that are based on originating IP address ranges. Julian Wright provided a useful link for requesting new features in iCloud on his response to my similar query on the same subject: https://discussions.apple.com/thread/4814943?answerId=21267558022#21267558022

If you are trying to block spam and phishing message on an IOS device, there are no straightforward ways. One user suggested using gmail as your email cloud service instead of iCloud. I haven't fully investigated it yet, but a cursory review does indicate that gmail's web-based filtering is much more sophisticated than iCloud's and you might be able to get it to delete SPAM before sending downstream to IOS clients.

If you would like the ability to use the iCloud filters to block messages based on the presence of any one in a range of IP addresses that appears anywhere in the "RECEIVED" fields of the header, then I invite you to submit your request, as I did (see the previous hyperlink for my request that Apple add this capability to iCloud), to: http://www.apple.com/feedback/icloud.html

Paul,

No problem. Please consider using the last link I provided to send a feature request to Apple allowing users to filter based on strings searches in the "Received" email header fields. I think getting the request form multiple users carries more weight than a single voice in the wilderness.

By the way, if you are interested, this is the script I use that bounces emails as they are downloaded into my mail.app I saved the script in my utility folder, then in the conditional filter, if the RECEIVED field contains a suspect IP address prefix (e.g., " [89.39.140. " -without the quote marks, but with the opening bracket and periods), it invokes two actions: 1 - invokes the "Bounce" Script , and 2 - performs a "move to the trash" command. The bounce generates a return message to the sender telling them that your address is unknown and the message is undeliverable. This function is controversial because a lot of spammers spoof the return addresses. But I believe it is useful to let anybody whose address is spoofed buy spammers know that they are being exploited. Here is the script that bounces the spam - I don't know if it works under 10.8, but it works under 10.6.8:

using terms from application "Mail"

on perform mail action with messagestheMessages

tell application "Mail"

repeat with eachMessage in theMessages

bounceeachMessage

end repeat

end tell

end perform mail action with messages

end using terms from

Sometimes, a Bounce message will be returned to your inbox as "undeliverable". For this condition, just generate another filter rule that searches on the subject of incoming messages and if it contains characteristic phrases of these messages, it directs them to the trash. That way, I don't have to expend any touch labor dispositioning failed bounce messages.

Good luck. Also, you might try getting an acccount with SPAMCOP, if you cut n past the raw text from an email (viewed by highlighting the message in your inbox and then hit option-cmd-u) SPAMCOP will track down the source IP address and resolve obfuscated links so you can get a clear view of the SPAMs origination point. SPAMCOP also allows you to send reports to abuse addresses associate with those IP addresses whether they are originating domains or merely linked domains referenced in the SPAM.

In addition to SPAMCOP, I also have taken to right clicking on SPAM in my inbox, selecting the "forward as attachment" function, and then sending them to spam@uce.gov and to my mail service providers' spam reporting service. I have an icloud account, a gmail account, and a timewarner roadrunner account. Both gmail and roadrunner are pretty aggressive in adding repeat offenders to their blacklists. Gmail has a nice option on top of processing the spam for blacklisting consideration: it offers to act as your agent to try to unsubscribe you from the spam's listservers.

Good luck

The verb bounce doesn't appear to exist in Mail's Applescript dictionary in 10.8.

The script might work with the verb redirect (which does exist), but whether that's the same thing or not I'm not entirely sure.

Like I said, I wan't sure this script would work in 10.7 and higher. I'm using 10.6.8, and it is still a valid script function.

I had heard reports that the "bounce" feature had been removed in later OSX versions. I suspect that this is because network administrators were complaining that bounces were creating a burden. Rather than address the root cause by isolating ranges of known SPAM IP address and cutting them off from the internet, they instead decided to stop the victims of SPAM from complaining to them by bouncing messages (often to a spoofed address that had nothing to do with the SPAM). I still cannot figure out why my icloud, roadrunner, or gmail webmail filters won't allow me to set up a direct to trash rule for all messages with a specified IP address or range of IP addresses appearing in the initial RECEIVED header field. These are the Networks who are bad actors. If individual users had the capacity to shut off all connections that originate from these miscreants, their behavior would change from within. Other legitimate users would demand that the administrators cutoff the SPAMMers.

Boggles my mind that mail servers don't allow clients to so filter. Fortunately, Apple mail does allow you to filter based on Recipient content, and so that is what I'm doing.