'Wildcard' DOMAIN Filtering on Mercury

Rolf Lindby

posted Feb 6 '14 at 7:22 pm

To be able to use MercuryS to receive mail you will first need to verify that your ISP allows access to port 25 (SMTP). If this is the case you will then need to point the MX record for your domain to the public address of your mail server. The MX record is expected to contain a hostname (like mail.mydomain.com), not a numerical IP address.

GJT

posted Jan 29 '14 at 12:17 pm

Hoping someone can help here... like many people I am inundated with spam email and although Pegasus does a good job filtering out most of the crud, I am regularly overcome with emails

from mailer type services that use variations on the same issuing domain. David Harris did reply previously to advise that Mercury can filter using a wildcard but the testing I have done confirms that

this feature for Mercury will only work where the domain sits adjacent to the ampersand character ie. @mailer.com

So, I had hoped to use a Killfile in conjunction with the Global Filtering rules withinin Mercury, to delete these emails . Two of the worst offfenders follow here :

\MATCH *.mcdlv.net

\MATCH *.mcsv.net

This is fine where the emails are of the following format : user@mcdlv.net / user@mcsv.net

However, I appear unable to block any of the following from being intercepted by Mercury, using the MATCH instruction given above.

user@abc.mcdlv.net , user@abc.123.mcdlv.net , user@abc.123.xyz.mcdlv.net

Does anyone know of a way to block these - alternatively, am I able to ask of the next version of Mercruy that the MATCH is all encompassing OR better still a new

MATCHALL command to delete these domain variants can be considered please?

Thanks in advance for any help/guidance offered.

Regards

Hoping someone can help here... like many people I am inundated with spam email and although Pegasus does a good job filtering out most of the crud, I am regularly overcome with emails from mailer type services that use variations on the same issuing domain. David Harris did reply previously to advise that Mercury can filter using a wildcard but the testing I have done confirms that&nbsp;this feature for Mercury will only work where the domain sits adjacent to the ampersand character ie. &nbsp;@mailer.com&nbsp;So, I had hoped to use a Killfile in conjunction with the Global Filtering rules withinin Mercury, to delete these emails . Two of the worst offfenders follow here :&nbsp;\MATCH *.mcdlv.net\MATCH *.mcsv.net&nbsp;This is fine where the emails are of the following format : user@mcdlv.net / &nbsp;user@mcsv.netHowever, I appear unable to block any of the following from being intercepted by Mercury, using the MATCH instruction given above.user@abc.mcdlv.net , &nbsp;user@abc.123.mcdlv.net&nbsp;,&nbsp;user@abc.123.xyz.mcdlv.net&nbsp;Does anyone know of a way to block these - alternatively, am I able to ask of the next version of Mercruy that the MATCH is all encompassing OR better still a new MATCHALL command to delete these domain variants can be considered please?&nbsp;Thanks in advance for any help/guidance &nbsp;offered.&nbsp;&nbsp;Regards&nbsp;&nbsp;

irelam

posted Jan 29 '14 at 5:19 pm

Why are you coding a period after the asterisk? The email addresses do not contain the period before the domain name.

Martin.

Why are you coding a period after the asterisk? The email addresses do not contain the period before the domain name.Martin.&nbsp;

GJT

posted Jan 29 '14 at 5:49 pm

Martin

Thanks for the reply...

>>The email addresses do not contain the period before the domain name.

But they do!....... as per my examples :

user@abc.123.xyz.mcdlv.net

*

The RED asterisk '*' shown above is directly underneath the period in question. The primary domain is mcdlv.net NOT (in this example), abc.123.xyz.mcdlv.net - which is what I have termed a 'variant' of the primary domain name...

I have tried various combinations and it just so happens what I have copied here is what I have taken from the 'killfile' and is what I had hoped

would work for the variants described... because the mails I am trying to avoid are those where there is a period in front of the actual domain name that we are trying to filter. (..is that clear ? ;-)

NOTE : you have stated 'after the ASTERISK', I stated ampersand - but, what we are both referring to is actually the @ character

G

Martin Thanks for the reply... &gt;&gt;The email addresses do not contain the period before the domain name.&nbsp; But they do!....... as per my examples : user@abc.123.xyz.mcdlv.net&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;*&nbsp; &nbsp;The RED asterisk '*' shown above is directly underneath the period in question. The primary domain is mcdlv.net NOT (in this example), abc.123.xyz.mcdlv.net - which is what I have termed a 'variant' of the primary domain name... I have tried various combinations and it just so happens what I have copied here is what I have taken from the 'killfile' and is what I had hoped would work for the variants described... because the mails I am trying to avoid are those where there is a period in front of the actual domain name that we are trying to filter. (..is that clear ? ;-) &nbsp;NOTE : you have stated 'after the ASTERISK', I stated ampersand - but, what we are both referring to is actually the @ character G&nbsp;

irelam

posted Jan 29 '14 at 6:08 pm

If that is the string you are trying to filter I would suggest:

*@*.domainName

Martin

If that is the string you are trying to filter I would suggest:*@*.domainNameMartin&nbsp;

GJT

posted Jan 30 '14 at 2:20 pm

Regretably, this proposal doesnt work...

Thanks for the suggestion... any other suggestions welcomed....!

Regretably, this proposal doesnt work...&nbsp;Thanks for the suggestion... any other suggestions welcomed....!&nbsp;

Rolf Lindby

posted Jan 31 '14 at 2:48 am

Assuming the same domain name is used in MAIL FROM in the SMTP envelope I would suggest using the transaction-level expression filter (MercuryS configuration / Compliance):

M, "*.mcdlv.net*", R, "554 Domain blocked due to previous spamming."

Assuming the same domain name is used in MAIL FROM in the SMTP envelope I would suggest using the transaction-level expression filter (MercuryS configuration / Compliance):M, "*.mcdlv.net*", R, "554 Domain blocked due to previous spamming."&nbsp;

irelam

posted Jan 31 '14 at 3:23 am

Hello again, I wrote a little test and the results are below. I am not using Mercury Regular Expressions but a unix lookalike.

Looking at: user@mcdlv.net (* Okay format *)

using mask: ?*\@?*.mcdlv.net

Length of data: 0

using mask: ?*\@?*.mcdlv.net

Looking in: user@abc.mcdlv.net(* domain name enlarged *)

Found: user@abc.mcdlv.net

String found at: 1

Length of data: 18

Looking in: user@abc.123.mcdlv.net (* domain name enlarged *)

using mask: ?*\@?*.mcdlv.net

Found: user@abc.123.mcdlv.net

String found at: 1

Length of data: 22

Looking in: user@abc.123.xyz.mcdlv.net (* domain name enlarged *)

using mask: ?*\@?*.mcdlv.net

Found: user@abc.123.xyz.mcdlv.net

String found at: 1

Length of data: 26

This is slightly different to my first suggestion. The ?* indicates any character followed by any number of characters. The\@ is to code the @ sign in escaped form. The following ?*. looks for any character repeated any number of times followed by .mcdlv.net

The same Mask value was used in each test. All you seem to need is the Mercury equivalent of this mask.

Martin

Hello again, I wrote a little test and the results are below. I am not using Mercury Regular Expressions but a unix lookalike.Looking at: user@mcdlv.net &nbsp; (* Okay format *)using mask: ?*\@?*.mcdlv.netLength of data: 0&nbsp;using mask: ?*\@?*.mcdlv.net &nbsp;Looking in: user@abc.mcdlv.net(* domain name enlarged *)Found: user@abc.mcdlv.netString found at: 1Length of data: 18&nbsp;Looking in: user@abc.123.mcdlv.net &nbsp;&nbsp;(* domain name enlarged *)using mask: ?*\@?*.mcdlv.netFound: user@abc.123.mcdlv.netString found at: 1Length of data: 22&nbsp;Looking in: user@abc.123.xyz.mcdlv.net &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(* domain name enlarged *)using mask: ?*\@?*.mcdlv.netFound: user@abc.123.xyz.mcdlv.netString found at: 1Length of data: 26This is slightly different to my first suggestion. The ?* indicates any character followed by any number of characters. The\@ is to code the @ sign in escaped form. The following ?*. looks for any character repeated any number of times followed by .mcdlv.netThe same Mask value was used in each test. All you seem to need is the Mercury equivalent of this mask.Martin&nbsp;&nbsp;&nbsp;

GJT

posted Jan 31 '14 at 12:15 pm

this looks very encouraging ! Thank you for the effort here....

The only remaining question is : who would know what the Mercury equivalent of this mask would be...? David himself perhaps... ?

this looks very encouraging ! Thank you for the effort here.... The only remaining question is : who would know what the Mercury equivalent of this mask would be...? David himself perhaps... ?&nbsp;&nbsp;

GJT

posted Jan 31 '14 at 12:29 pm

[quote user="Rolf Lindby"]

Assuming the same domain name is used in MAIL FROM in the SMTP envelope I would suggest using the transaction-level expression filter (MercuryS configuration / Compliance):

M, "*.mcdlv.net*", R, "554 Domain blocked due to previous spamming."

[/quote]

Hi

I am and have been using Mercury C (SMTP Relay Client) and Mercury D (POP3 Distributing Client) modules for many years with great success.

Following your suggestion I have now added the Mercury S module in order to use the Compliance feature... is there anything else I need to

configure in Mercury S, because it doesnt seem to be doing anything at all... no messages in the panels etc.

Thank you.

G

[quote user="Rolf Lindby"]Assuming the same domain name is used in MAIL FROM in the SMTP envelope I would suggest using the transaction-level expression filter (MercuryS configuration / Compliance):M, "*.mcdlv.net*", R, "554 Domain blocked due to previous spamming."&nbsp;[/quote]&nbsp;HiI am and have been using Mercury C (SMTP Relay Client) &nbsp;and Mercury D (POP3 Distributing Client) modules for many years with great success.Following your suggestion I have now added the Mercury S module in order to use the Compliance feature... is there anything else I need toconfigure in Mercury S, because it doesnt seem to be doing anything at all... no messages in the panels etc.&nbsp;Thank you.G&nbsp;&nbsp;

GJT

posted Jan 31 '14 at 12:30 pm

[quote user="irelam"]

Hello again, I wrote a little test and the results are below. I am not using Mercury Regular Expressions but a unix lookalike.

Looking at: user@mcdlv.net (* Okay format *)

using mask: ?*\@?*.mcdlv.net

Length of data: 0

using mask: ?*\@?*.mcdlv.net

Looking in: user@abc.mcdlv.net(* domain name enlarged *)

Found: user@abc.mcdlv.net

String found at: 1

Length of data: 18

Looking in: user@abc.123.mcdlv.net (* domain name enlarged *)

using mask: ?*\@?*.mcdlv.net

Found: user@abc.123.mcdlv.net

String found at: 1

Length of data: 22

Looking in: user@abc.123.xyz.mcdlv.net (* domain name enlarged *)

using mask: ?*\@?*.mcdlv.net

Found: user@abc.123.xyz.mcdlv.net

String found at: 1

Length of data: 26

This is slightly different to my first suggestion. The ?* indicates any character followed by any number of characters. The\@ is to code the @ sign in escaped form. The following ?*. looks for any character repeated any number of times followed by .mcdlv.net

The same Mask value was used in each test. All you seem to need is the Mercury equivalent of this mask.

Martin

[/quote]

this looks very encouraging ! Thank you for the effort here....

The only remaining question is : who would know what the Mercury equivalent of this mask would be...? David himself perhaps... ?

[quote user="irelam"]Hello again, I wrote a little test and the results are below. I am not using Mercury Regular Expressions but a unix lookalike.Looking at: user@mcdlv.net &nbsp; (* Okay format *)using mask: ?*\@?*.mcdlv.netLength of data: 0&nbsp;using mask: ?*\@?*.mcdlv.net &nbsp;Looking in: user@abc.mcdlv.net(* domain name enlarged *)Found: user@abc.mcdlv.netString found at: 1Length of data: 18&nbsp;Looking in: user@abc.123.mcdlv.net &nbsp;&nbsp;(* domain name enlarged *)using mask: ?*\@?*.mcdlv.netFound: user@abc.123.mcdlv.netString found at: 1Length of data: 22&nbsp;Looking in: user@abc.123.xyz.mcdlv.net &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(* domain name enlarged *)using mask: ?*\@?*.mcdlv.netFound: user@abc.123.xyz.mcdlv.netString found at: 1Length of data: 26This is slightly different to my first suggestion. The ?* indicates any character followed by any number of characters. The\@ is to code the @ sign in escaped form. The following ?*. looks for any character repeated any number of times followed by .mcdlv.netThe same Mask value was used in each test. All you seem to need is the Mercury equivalent of this mask.Martin&nbsp;&nbsp;&nbsp;[/quote]&nbsp;this looks very encouraging ! Thank you for the effort here....The only remaining question is : who would know what the Mercury equivalent of this mask would be...? David himself perhaps... ?&nbsp;

Rolf Lindby

posted Feb 1 '14 at 1:04 am

To be able to use MercuryS for receiving mail you will need to point the MX record for your domain to the Internet address of the Mercury server. If this isn't possible, for instance if the Internet provider won't allow access to port 25, you are unfortunately stuck with collecting mail from a domain mailbox hosted by some other party.

To be able to use MercuryS for receiving mail you will need to point the MX record for your domain to the Internet address of the Mercury server. If this isn't possible, for instance if the Internet provider won't allow access to port 25, you are unfortunately stuck with collecting mail from a domain mailbox hosted by some other party.&nbsp;

bfluet

posted Feb 3 '14 at 12:15 am

Could a global rule work here, specifically an expression rule (they accepts wild cards)? For example, if you wanted to detect the existence of "sam" anywhere in the From: header you would create an expressing rule that detects:

From:*sam*

Obviously you would need to create the rule specific to the header and content you need to detect.

Could a global rule work here, specifically an expression rule (they accepts wild cards)?&nbsp; For example, if you wanted to detect the existence of "sam" anywhere in the From: header you would create an expressing rule that detects:From:*sam*Obviously you would need to create the rule specific to the header and content you need to detect.

GJT

posted Feb 3 '14 at 10:06 am

[quote user="bfluet"]

Could a global rule work here, specifically an expression rule (they accepts wild cards)? For example, if you wanted to detect the existence of "sam" anywhere in the From: header you would create an expressing rule that detects:

From:*sam*

Obviously you would need to create the rule specific to the header and content you need to detect.

[/quote]

See my very first post - I currently use a Killfile in Global Rules.... but the MATCH command used in this file does not seem to like the format of wildcard characters I require to filter out these domains...

Becuase of the number of domains I want to avoid - I figured a flat file would be preferable as opposed to writing a new rule for each and every domain I encounter..

[quote user="bfluet"]Could a global rule work here, specifically an expression rule (they accepts wild cards)?&nbsp; For example, if you wanted to detect the existence of "sam" anywhere in the From: header you would create an expressing rule that detects:From:*sam*Obviously you would need to create the rule specific to the header and content you need to detect. [/quote]See my very first post - I currently use a Killfile in Global Rules.... &nbsp;but the MATCH command used in this file does not seem to like the format of wildcard characters I require to filter out these domains...Becuase of the number of domains I want to avoid - I figured a flat file would be preferable as opposed to writing a new rule for each and every domain I encounter..

David Harris

posted Feb 3 '14 at 10:28 pm

[quote user="GJT"]

See my very first post - I currently use a Killfile in Global Rules....

but the MATCH command used in this file does not seem to like the

format of wildcard characters I require to filter out these domains...

Becuase

of the number of domains I want to avoid - I figured a flat file would

be preferable as opposed to writing a new rule for each and every domain

I encounter..

[/quote]

It looks as though you need to end each expression with a closure (i.e, another asterisk).

So, to filter out everything from any system within the domain mcdlv.net, you need to use the expression \MATCH *mcdlv.net*

The reason for this is that the match expression must match the *entire* address string: as the address string is probably enclosed in angle brackets (like "<user1@mcdlv.net>"), without the trailing closure, the closing '>' will prevent the match.

It would probably be good to have the rule engine perform complete address reduction on the addresses before attempting the match: I'll consider doing that, although like everything to do with a program that has been around for so long, I'll want to do some testing on it to make sure it doesn't impact too many existing rule sets.

Cheers!

-- David --

[quote user="GJT"]See my very first post - I currently use a Killfile in Global Rules.... &nbsp;but the MATCH command used in this file does not seem to like the format of wildcard characters I require to filter out these domains...Becuase of the number of domains I want to avoid - I figured a flat file would be preferable as opposed to writing a new rule for each and every domain I encounter..[/quote] It looks as though you need to end each expression with a closure (i.e, another asterisk). So, to filter out everything from any system within the domain mcdlv.net, you need to use the expression \MATCH *mcdlv.net* The reason for this is that the match expression must match the *entire* address string: as the address string is probably enclosed in angle brackets (like "&lt;user1@mcdlv.net&gt;"), without the trailing closure, the closing '&gt;' will prevent the match. It would probably be good to have the rule engine perform complete address reduction on the addresses before attempting the match: I'll consider doing that, although like everything to do with a program that has been around for so long, I'll want to do some testing on it to make sure it doesn't impact too many existing rule sets. Cheers! -- David --

GJT

posted Feb 4 '14 at 12:26 pm

David

Thanks for the response.... however.... despite your suggestion : \MATCH *mcdlv.net* , the following got through .... which specific address entries in the headers of the email does Mercury check the Killfile entries against?...
The email header in question follows below....

Thanks

Guy

==============================================

Received: from spooler by palatineprecision.co.uk (Mercury/32 v4.73); 4 Feb 2014 11:13:38 -0000

X-Envelope-To: sales@palatineprecision.co.uk

Received: from POP3D by palatineprecision.co.uk with MercuryD (v4.73); 4 Feb 2014 11:13:19 -0000

Return-path: <bounce-mc.us4_9445429.697433-sales=palatineprecision.co.uk@mail48.wdc01.mcdlv.net>

Delivery-date: Tue, 04 Feb 2014 11:12:56 +0000

Received: from [205.201.129.48] (helo=mail48.wdc01.mcdlv.net)

by athena.hosts.co.uk with esmtp (Exim 4.80.1)

(envelope-from <bounce-mc.us4_9445429.697433-sales=palatineprecision.co.uk@mail48.wdc01.mcdlv.net>)

id 1WAdvz-0000Y2-3q

for sales@palatineprecision.co.uk; Tue, 04 Feb 2014 11:12:56 +0000

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=k1; d=mail48.wdc01.mcdlv.net;

h=Subject:From:Reply-To:To:Date:Message-ID:List-Unsubscribe:Sender:Content-Type:MIME-Version; i=enquiries=3Dqimtek.co.uk@mail48.wdc01.mcdlv.net;

bh=zmlzrozk3XGZYY1ZIGRWmZv1d9o=;

b=YJzc291hb1biVRfPle13L6R2v8VF9yKyfuH9PdeiDZeE1dsvt8x3hcVlc3AVPPHXoLj9WlhMSiwh

b+bAXyXsZLmYCwZRKcqf2XbZNzEYTsEdiiKXi5XNGMAzLxpIqFgLrpQt2M80uoj4mYRVDp/MjOwK

gpXZ0Dgwl/gQp9cGvgI=

DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=k1; d=mail48.wdc01.mcdlv.net;

b=YDVRys0UpF9pss5HojecqQ7Lte2GVn5LA+skMFpGTr93AJ/zi9pp+nDzM8VQHx3YxiuirFHQ/tgS

Ou9qBwm9oyaKoihQ37gaY6eocHbtKnlfiDmkOIy1VPIyN1UY1DoW4PnJ91WRsoxbPTvoXkMamTOk

V3AmwBgStthkyLvQSFI=;

Received: from (127.0.0.1) by mail48.wdc01.mcdlv.net id hu35je174e0o for <sales@palatineprecision.co.uk>; Tue, 4 Feb 2014 11:03:28 +0000 (envelope-from <bounce-mc.us4_9445429.697433-sales=palatineprecision.co.uk@mail48.wdc01.mcdlv.net>)

Subject: =?utf-8?Q?Update=20Your=20FREE=20Engineering=20Supplier=20Listing...?=

From: =?utf-8?Q?Qimtek=20Supplier=20Directory?= <enquiries@qimtek.co.uk>

Reply-To: =?utf-8?Q?Qimtek=20Supplier=20Directory?= <enquiries@qimtek.co.uk>

To: =?utf-8?Q?Guy?= <sales@palatineprecision.co.uk>

Date: Tue, 4 Feb 2014 11:03:28 +0000

Message-ID: <91ccbcc0b80e912f9899485924affa29bab.20140204110257@mail48.wdc01.mcdlv.net>

X-Mailer: MailChimp Mailer - **CIDc7210877424affa29bab**

X-Campaign: mailchimp91ccbcc0b80e912f989948592.c721087742

X-campaignid: mailchimp91ccbcc0b80e912f989948592.c721087742

X-Report-Abuse: Please report abuse for this campaign here: http://www.mailchimp.com/abuse/abuse.phtml?u=91ccbcc0b80e912f989948592&id=c721087742&e=4affa29bab

X-MC-User: 91ccbcc0b80e912f989948592

X-Feedback-ID: 9445429:9445429.697433:us4:mc

x-accounttype: pd

List-Unsubscribe: <mailto:unsubscribe-91ccbcc0b80e912f989948592-c721087742-4affa29bab@mailin1.us2.mcsv.net?subject=unsubscribe>, <http://qimtek.us4.list-manage.com/unsubscribe?u=91ccbcc0b80e912f989948592&id=f38e9d5980&e=4affa29bab&c=c721087742>

Sender: "Qimtek Supplier Directory" <enquiries=qimtek.co.uk@mail48.wdc01.mcdlv.net>

x-mcda: FALSE

Content-Type: multipart/alternative; boundary="_----------=_MCPart_1333020285"

MIME-Version: 1.0

X-namesco: 192.168.0.112

X-Spam-Score: 1.3 (+)

X-Original-To: sales@palatineprecision.co.uk

X-UC-Weight: [# ] 50

X-CC-Diagnostic: Subject matches "*/cFREE[E!*, ]*" (50)

X-PMFLAGS: 570949952 0 16646145 YEPMTRP5.CNM

DavidThanks for the response.... however.... despite your suggestion :&nbsp;\MATCH *mcdlv.net*&nbsp;, the following got through .... which specific address entries in the headers of the email does Mercury check the Killfile entries against?... The email header in question follows below....ThanksGuy&nbsp;==============================================&nbsp;Received: from spooler by palatineprecision.co.uk (Mercury/32 v4.73); 4 Feb 2014 11:13:38 -0000X-Envelope-To: sales@palatineprecision.co.ukReceived: from POP3D by palatineprecision.co.uk with MercuryD (v4.73); 4 Feb 2014 11:13:19 -0000Return-path: &lt;bounce-mc.us4_9445429.697433-sales=palatineprecision.co.uk@mail48.wdc01.mcdlv.net&gt;Delivery-date: Tue, 04 Feb 2014 11:12:56 +0000Received: from [205.201.129.48] (helo=mail48.wdc01.mcdlv.net) by athena.hosts.co.uk with esmtp (Exim 4.80.1) (envelope-from &lt;bounce-mc.us4_9445429.697433-sales=palatineprecision.co.uk@mail48.wdc01.mcdlv.net&gt;) id 1WAdvz-0000Y2-3q for sales@palatineprecision.co.uk; Tue, 04 Feb 2014 11:12:56 +0000DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=k1; d=mail48.wdc01.mcdlv.net;&nbsp;h=Subject:From:Reply-To:To:Date:Message-ID:List-Unsubscribe:Sender:Content-Type:MIME-Version; i=enquiries=3Dqimtek.co.uk@mail48.wdc01.mcdlv.net;&nbsp;bh=zmlzrozk3XGZYY1ZIGRWmZv1d9o=;&nbsp;b=YJzc291hb1biVRfPle13L6R2v8VF9yKyfuH9PdeiDZeE1dsvt8x3hcVlc3AVPPHXoLj9WlhMSiwh&nbsp; &nbsp;b+bAXyXsZLmYCwZRKcqf2XbZNzEYTsEdiiKXi5XNGMAzLxpIqFgLrpQt2M80uoj4mYRVDp/MjOwK&nbsp; &nbsp;gpXZ0Dgwl/gQp9cGvgI=DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=k1; d=mail48.wdc01.mcdlv.net;&nbsp;b=YDVRys0UpF9pss5HojecqQ7Lte2GVn5LA+skMFpGTr93AJ/zi9pp+nDzM8VQHx3YxiuirFHQ/tgS&nbsp; &nbsp;Ou9qBwm9oyaKoihQ37gaY6eocHbtKnlfiDmkOIy1VPIyN1UY1DoW4PnJ91WRsoxbPTvoXkMamTOk&nbsp; &nbsp;V3AmwBgStthkyLvQSFI=;Received: from (127.0.0.1) by mail48.wdc01.mcdlv.net id hu35je174e0o for &lt;sales@palatineprecision.co.uk&gt;; Tue, 4 Feb 2014 11:03:28 +0000 (envelope-from &lt;bounce-mc.us4_9445429.697433-sales=palatineprecision.co.uk@mail48.wdc01.mcdlv.net&gt;)Subject: =?utf-8?Q?Update=20Your=20FREE=20Engineering=20Supplier=20Listing...?=From: =?utf-8?Q?Qimtek=20Supplier=20Directory?= &lt;enquiries@qimtek.co.uk&gt;Reply-To: =?utf-8?Q?Qimtek=20Supplier=20Directory?= &lt;enquiries@qimtek.co.uk&gt;To: =?utf-8?Q?Guy?= &lt;sales@palatineprecision.co.uk&gt;Date: Tue, 4 Feb 2014 11:03:28 +0000Message-ID: &lt;91ccbcc0b80e912f9899485924affa29bab.20140204110257@mail48.wdc01.mcdlv.net&gt;X-Mailer: MailChimp Mailer - **CIDc7210877424affa29bab**X-Campaign: mailchimp91ccbcc0b80e912f989948592.c721087742X-campaignid: mailchimp91ccbcc0b80e912f989948592.c721087742X-Report-Abuse: Please report abuse for this campaign here: http://www.mailchimp.com/abuse/abuse.phtml?u=91ccbcc0b80e912f989948592&amp;id=c721087742&amp;e=4affa29babX-MC-User: 91ccbcc0b80e912f989948592X-Feedback-ID: 9445429:9445429.697433:us4:mcx-accounttype: pdList-Unsubscribe: &lt;mailto:unsubscribe-91ccbcc0b80e912f989948592-c721087742-4affa29bab@mailin1.us2.mcsv.net?subject=unsubscribe&gt;, &lt;http://qimtek.us4.list-manage.com/unsubscribe?u=91ccbcc0b80e912f989948592&amp;id=f38e9d5980&amp;e=4affa29bab&amp;c=c721087742&gt;Sender: "Qimtek Supplier Directory" &lt;enquiries=qimtek.co.uk@mail48.wdc01.mcdlv.net&gt;x-mcda: FALSEContent-Type: multipart/alternative; boundary="_----------=_MCPart_1333020285"MIME-Version: 1.0X-namesco: 192.168.0.112X-Spam-Score: 1.3 (+)X-Original-To: sales@palatineprecision.co.ukX-UC-Weight: [# &nbsp; ] 50X-CC-Diagnostic: Subject matches "*/cFREE[E!*, ]*" (50)X-PMFLAGS: 570949952 0 16646145 YEPMTRP5.CNM &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;

David Harris

posted Feb 6 '14 at 11:05 am

[quote user="GJT"]

Thanks for the response.... however.... despite your suggestion : \MATCH *mcdlv.net* , the following got through .... which specific address entries in the headers of the email does Mercury check the Killfile entries against?...

The email header in question follows below....

[/quote]

It checks the From: and Reply-to fields only. It does not check the "Sender" field, which would have been required to catch this example. A quick look at the Mercury code suggests that changing this is a larger job than I'm willing to undertake so near to a significant release (v4.8 is in gold release candidate testing at the moment).

In fairness, the listscan rule action was never intended for use as a rigorous anti-spam measure: the feature in the program most suited to your purpose is the MercuryS killfile or transaction filtering options, but of course they're not much help in your case because you're using MercuryD. I'm happy to consider adding a blacklisting capability to MercuryD for the next release, but regrettably it's just too late to get it into v4.8.

Cheers!

-- David --

[quote user="GJT"] Thanks for the response.... however.... despite your suggestion :&nbsp;\MATCH *mcdlv.net*&nbsp;, the following got through .... which specific address entries in the headers of the email does Mercury check the Killfile entries against?... The email header in question follows below....[/quote] It checks the From: and Reply-to fields only. It does not check the "Sender" field, which would have been required to catch this example. A quick look at the Mercury code suggests that changing this is a larger job than I'm willing to undertake so near to a significant release (v4.8 is in gold release candidate testing at the moment). In fairness, the listscan rule action was never intended for use as a rigorous anti-spam measure: the feature in the program most suited to your purpose is the MercuryS killfile or transaction filtering options, but of course they're not much help in your case because you're using MercuryD. I'm happy to consider adding a blacklisting capability to MercuryD for the next release, but regrettably it's just too late to get it into v4.8. Cheers! -- David --

GJT

posted Feb 6 '14 at 3:34 pm

OK David, the blacklist feature against <Sender> would be a great help here.... please add to your list for the next release of Mercury..

On another note.... am I able to configure Mercury S for use on my system in order to use the killfile and transaction level processing in the short term...?

What are the prerequisites to use Mercury S?
...............I have an ISP that provides my internet/broadband connection . Mercury sits on a Windows Vista PC (my dedicated mail server machine), and I have configured Mercury D to poll every minute to retrieve email from the hosted domain.

Mercury SMTP delivers to users' mailboxes on our LAN.

Will Mercury S work on this setup and are the config. changes required extensive to get this to work.. ?

OK David, the blacklist feature against &lt;Sender&gt; would be a great help here.... please add to your list for the next release of Mercury..On another note.... am I able to configure Mercury S for use on my system in order to use the killfile and transaction level processing in the short term...?What are the prerequisites to use Mercury S? ...............I have an ISP that provides my internet/broadband connection . Mercury sits on a Windows Vista PC (my dedicated mail server machine), and I have configured Mercury D to poll every minute to retrieve email from the hosted domain. Mercury SMTP delivers to users' mailboxes on our LAN.Will Mercury S work on this setup and are the config. changes required extensive to get this to work.. ?

Related Topics

Pending draft

Confirm move posts

Insufficient permissions

Select a different topic

Edit history