Community Discussions and Support
Blocking by IP address in "received" headers

I agree with the above comments about blocking the rest of the world being not the smartest method to combat spam. However, if you want to use this approach for some reason you could do it by using the Blacklist feature of MercuryS and either query the ip-to-country list at http://countries.nerd.dk/ for uk.countries.nerd.dk and let Mercury add a header on which you can filter later, or, if you want to block foreign IP's at the SMTP level you could set the strictness level in the Blacklist definition setup to 'range', query zz.countries.nerd.dk instead and block everything above and below 127.0.3.58, which is UK.

To mitigate the effect of blocking foreign IP's somewhat you could also set up a Whitelist in MercuryS and query a public whitelist like http://www.dnswl.org/ before.

Best regards

Nico

I agree with the above comments about blocking the rest of the world being not the smartest method to combat spam. However, if you want to use this approach for some reason you could do it by using the Blacklist feature of MercuryS and either query the ip-to-country list at http://countries.nerd.dk/ for uk.countries.nerd.dk and let Mercury add a header on which you can filter later, or, if you want to block foreign IP's at the SMTP level you could set the strictness level in the Blacklist definition setup to 'range', query zz.countries.nerd.dk instead and block everything above and below 127.0.3.58, which is UK. To mitigate the effect of blocking foreign IP's somewhat you could also set up a Whitelist in MercuryS and query a public whitelist like http://www.dnswl.org/ before. Best regards Nico

I'm still using v4.01b and would like to use spambust.dat to block IP ranges in received headers but can't get my head round the exact format of the rule I have to make.  If I use: if header"received" contains "118.*.*.*" it will block any received header with 118 anywhere in it - what I want to do is block a received header that contains 118 as the start of a string of numbers in dotted IP format.  Ideally I need a rule that will block IP ranges so I can exclude entire swathes of the planet or an entire ISP.

 Anyone got a clue?

or should I just forget the whole thing and start using 4.5.2 and the spamhalter feature?
 

<p>I'm still using v4.01b and would like to use spambust.dat to block IP ranges in received headers but can't get my head round the exact format of the rule I have to make.  If I use: if header"received" contains "118.*.*.*" it will block any received header with 118 anywhere in it - what I want to do is block a received header that contains 118 as the start of a string of numbers in dotted IP format.  Ideally I need a rule that will block IP ranges so I can exclude entire swathes of the planet or an entire ISP.</p><p> Anyone got a clue?</p><p>or should I just forget the whole thing and start using 4.5.2 and the spamhalter feature?  </p>

First: You need to install the 4.01c security patch now, preferably before reading any more of this post!

Secondly:  Blocking by A-nets or IP ranges seems a rather bad idea. Upgrading to 4.5.2 and using SpamHalter and/or Graywall, in combination with a reputable blocklist like Spamhaus if you like, will be safer and require much less maintenance.

/Rolf

 

<p>First: You need to install the 4.01c security patch now, preferably before reading any more of this post! </p><p>Secondly:  Blocking by A-nets or IP ranges seems a rather bad idea. Upgrading to 4.5.2 and using SpamHalter and/or Graywall, in combination with a reputable blocklist like Spamhaus if you like, will be safer and require much less maintenance.</p><p>/Rolf </p><p> </p>

[quote user="hozza12163"]...or should I just forget the whole thing and start using 4.5.2 and the spamhalter feature? [/quote]

I agree with what Rolf recommends.

And a minor point, if you don't want to upgrade to the 4.5x versions for some reason, Spamhalter runs fine with v4.01c.  It's only Graywall which you can't run with the older version.

<P>[quote user="hozza12163"]...or should I just forget the whole thing and start using 4.5.2 and the spamhalter feature? [/quote]</P> <P>I agree with what Rolf recommends.</P> <P>And a minor point, if you don't want to upgrade to the 4.5x versions for some reason, Spamhalter runs fine with v4.01c.  It's only Graywall which you can't run with the older version.</P>

Ah, that's true, SpamHalter did of course exist before the new daemon interface in Mercury 4.5 was created. It can be downloaded directly from Lukas' site:

http://www.ararat.cz/eng/show.php?spamhalter

/Rolf 

<p>Ah, that's true, SpamHalter did of course exist before the new daemon interface in Mercury 4.5 was created. It can be downloaded directly from Lukas' site:</p><p>http://www.ararat.cz/eng/show.php?spamhalter</p><p>/Rolf </p>

[quote user="Rolf Lindby"]

First: You need to install the 4.01c security patch now, preferably before reading any more of this post!

Secondly:  Blocking by A-nets or IP ranges seems a rather bad idea. Upgrading to 4.5.2 and using SpamHalter and/or Graywall, in combination with a reputable blocklist like Spamhaus if you like, will be safer and require much less maintenance.

/Rolf

 

[/quote]

This patch corrects a vulnerability and addresses some memory leaks in the MercuryI IMAP server. 

 

This seems to me to be a patch for IMAP - I don't use IMAP so it seems irrelevant to me....

 

I can't see why blocking IP addresses would be a bad idea as every email I receive shows the IP of the server that sent the mail and the vast majority of my legit email comes from the UK.  I can exclude just about anything that comes from offshore servers by blocking a range of IP addresses  - I just need the format of the rule to do this if anyone has any idea?

 

Thanks for the advice 

[quote user="Rolf Lindby"]<p>First: You need to install the 4.01c security patch now, preferably before reading any more of this post! </p><p>Secondly:  Blocking by A-nets or IP ranges seems a rather bad idea. Upgrading to 4.5.2 and using SpamHalter and/or Graywall, in combination with a reputable blocklist like Spamhaus if you like, will be safer and require much less maintenance.</p><p>/Rolf </p><p> </p><p>[/quote] This patch corrects a vulnerability and addresses some memory leaks in the MercuryI IMAP server.  </p><p> </p><p>This seems to me to be a patch for IMAP - I don't use IMAP so it seems irrelevant to me....</p><p> </p><p>I can't see why blocking IP addresses would be a bad idea as every email I receive shows the IP of the server that sent the mail and the vast majority of my legit email comes from the UK.  I can exclude just about anything that comes from offshore servers by blocking a range of IP addresses  - I just need the format of the rule to do this if anyone has any idea?</p><p> </p><p>Thanks for the advice </p>

The 4.01c patch fixes a buffer overflow in the MercuryS AUTH command.  There has been at least one system successfully compromised via this vulnerability.  http://community.pmail.com/files/folders/patches/entry3931.aspx

The 4.01c patch fixes a buffer overflow in the MercuryS AUTH command.  There has been at least one system successfully compromised via this vulnerability.  http://community.pmail.com/files/folders/patches/entry3931.aspx

I'm afraid it would be a bit of a mess to try to build extensive IP range filters in content control. In most cases you would need to use regular expressions and a MATCHES test. See the information in Mercury help about this, and this example from spambust.dat:

# Check for subject lines ending with a date/time stamp.  e.g. "3/10/02 8:14:07 PM"
if Subject matches "*[0-9]+/[0-9]+/[0-9]+ +[0-9]+:[0-9]+:[0-9]+ +[AP]M" weight 77

In this case it's a date/time value with some fixed separators, but you can probably with some work apply the same kind of rule to IP numbers.

This is however not really what content control was built to do. It would be more efficient to write a special daemon to handle it if you feel strongly about this approach. Personally I still think it would be better to use Mercury's other spam-blocking techniques, like SpamHalter.

/Rolf 

<p>I'm afraid it would be a bit of a mess to try to build extensive IP range filters in content control. In most cases you would need to use regular expressions and a MATCHES test. See the information in Mercury help about this, and this example from spambust.dat: </p><blockquote><i># Check for subject lines ending with a date/time stamp.  e.g. "3/10/02 8:14:07 PM"</i> <i>if Subject matches "*[0-9]+/[0-9]+/[0-9]+ +[0-9]+:[0-9]+:[0-9]+ +[AP]M" weight 77</i> </blockquote><p>In this case it's a date/time value with some fixed separators, but you can probably with some work apply the same kind of rule to IP numbers.</p><p>This is however not really what content control was built to do. It would be more efficient to write a special daemon to handle it if you feel strongly about this approach. Personally I still think it would be better to use Mercury's other spam-blocking techniques, like SpamHalter.</p><p>/Rolf </p>

hozza12163 wrote:

This seems to me to be a patch for IMAP - I don't use IMAP so it seems irrelevant to me....

 No, the vulnerability it patches is in the SMTP server, it's only the memory leaks that IMAP related

 The patch is trivial to implement so better to be safe.

Sorry, I don't know the answer to your question on rule structure

<p>hozza12163 wrote:</p><p style="margin-left: 40px;">This seems to me to be a patch for IMAP - I don't use IMAP so it seems irrelevant to me....</p><p> No, the vulnerability it patches is in the SMTP server, it's only the memory leaks that IMAP related</p><p> The patch is trivial to implement so better to be safe. </p><p>Sorry, I don't know the answer to your question on rule structure </p>
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft