Message killed by filtering rule enigma

Greenman

posted Jul 1 '15 at 6:23 pm

[quote user="PaulW"][quote user="Greenman"][quote user="Rolf Lindby"]

The way I understood it the message arrived from an external distribution list to local user A, was forwarded using Pegasus Mail to local user B, resulting in the forwarded message being killed by Mercury, but that was maybe not actually the case?

[/quote]

You are almost right. The external message was addressed to local user A who forwarded it via a distribution list to several local users B, C, D, E etc.

However, the original message was delivered by Mercury without being 'killed'.[/quote]

Is this just happening to one user or several? And how is it being forwarded - bounce or fwd with edit?

[/quote]

They tried it with forward as edit, and forward as attachment. Did not use the bounce option as they needed to introduce the message.

[quote user="PaulW"][quote user="Greenman"][quote user="Rolf Lindby"] The way I understood it the message arrived from an external distribution list to local user A, was forwarded using Pegasus Mail to local user B, resulting in the forwarded message being killed by Mercury, but that was maybe not actually the case? [/quote] You are almost right.&nbsp;The external message&nbsp;was addressed to local&nbsp;user A who forwarded it via a distribution list to several local users B, C, D, E etc. However, the original message was delivered by Mercury without being 'killed'.[/quote] Is this just happening to one user or several?&nbsp; And how is it being forwarded - bounce or fwd with edit? [/quote] They&nbsp;tried it with forward as edit, and forward as attachment. Did not use the bounce option as they needed to introduce the message.

Greenman

posted Jun 16 '15 at 6:29 pm

Hi

One of our members of staff had an issue where forwarding a message via Pegasus Mail to a distribution list (all addresses are local and in the format firstname.lastname@ourdomain.com) kept failing to be sent. When I checked Mercury it reported 'killed by filtering rule'

Tried changing the subject line, the content, forwarding the original message as an attachment - all were 'killed by filtering rule'.

When the message is forwarded to just one recipient it succeeds.

Any idea why?

Hi One of our members of staff had an issue where forwarding a message via Pegasus Mail&nbsp;to a distribution list (all addresses are local and in the format <A href="mailto:firstname.lastname@ourdomain.com">firstname.lastname@ourdomain.com</A>) kept failing to be sent. When I checked Mercury it reported 'killed by filtering rule' Tried changing the subject line, the content, forwarding the original message as an attachment - all were 'killed by filtering rule'. When the message is forwarded to just one recipient it succeeds. Any idea why?

Brian Fluet

posted Jun 16 '15 at 7:53 pm

No doubt you have already looked for something in a global rule or outgoing rule that is being triggered but don't see it. Have you tried forwarding the message to each recipient independently to see if you can identify one that is triggering a rule?

I hate that you are running into the type of issue I could only resolve by running a second instance.

No doubt you have already looked for something in a global rule or outgoing rule that is being triggered but don't see it.&nbsp; Have you tried forwarding the message to each recipient independently to see if you can identify one that is triggering a rule?I hate that you are running into the type of issue I could only resolve by running a second instance.

Greenman

posted Jun 17 '15 at 11:24 am

Thanks for responding, Brian

Yes, this is the second time we have encountered this.

I have been through all the filtering rules. There is only one rule that deletes messages and that is a rule that is part of a set that checks outgoing message sizes (anything over 25MB is deleted and the sender is notified). The message in question is well within this limit and also this is an internal message so that rule would not have been triggered.

Luckily, the distribution list only comprised 10 internal addresses so although a faff, it was not too much hassle for the person to forward the message separately to each recipient.

Thanks for responding, Brian Yes, this is the second time we have encountered this. I have been through all&nbsp;the filtering rules. There is only one rule that deletes messages and that is a rule that is part of a set that checks outgoing message sizes (anything over 25MB is deleted and the sender is notified). The message in question is well within this limit and also this is an internal message so that rule would not have been triggered. Luckily, the distribution list only comprised 10 internal addresses so although a faff, it was not too much hassle for the person to forward the message&nbsp;separately to each recipient.

Brian Fluet

posted Jun 17 '15 at 2:29 pm

Sending to each recipient works but as a dlist it gets killed by a filtering rule. How strange, but very reminiscent of my experiences. My kills weren't dlists though, at least not that I remember.

Sending to each recipient works but as a dlist it gets killed by a filtering rule.&nbsp; How strange, but very reminiscent of my experiences.&nbsp; My kills weren't dlists though, at least not that I remember.

Greenman

posted Jun 17 '15 at 5:46 pm

I just don't understand why Mercury kills it. We don't use Spamhalter or anything like that either (all our inbound/outbound mail is filtered by a professional filtering service in the cloud).

Anyone else have any ideas what may be causing this?

I just don't understand why Mercury kills it. We don't use Spamhalter or anything like that either (all our inbound/outbound mail is filtered by a professional filtering service in the cloud). Anyone else have any ideas what may be causing this?

Greenman

posted Jun 18 '15 at 11:18 am

Perhaps a better question would be what causes Mercury to 'kill' a message?

As I said there is just one filtering rule that deletes outgoing messages larger than 25MB (well, 27MB), and there are other rules that notify the sender.

Outgoing rules

I can't see what else may be causing Mercury to drop these messages.

Perhaps a better question would be what causes Mercury to 'kill' a message? As I said there is just one filtering rule that deletes outgoing messages larger than 25MB (well, 27MB), and there are other rules that notify the sender. <IMG title="Outgoing rules" style="HEIGHT: 76px; WIDTH: 389px" alt="Outgoing rules" src="http://img540.imageshack.us/img540/510/rBUokp.jpg" width=389 height=76 mce_src="http://img540.imageshack.us/img540/510/rBUokp.jpg"> I can't see what else may be causing Mercury to drop these messages.&nbsp; &nbsp;

Sellerie

posted Jun 19 '15 at 11:35 pm

Email users can be puzzled by size limits because the MIME encoding, which typically uses Base64 adds ~33% overhead – so that a 20MB document on disk exceeds a 25MB file attachment limit. After reading the Mercury help, i think that i found an answer:

[quote user="Actions that can be performed by a filtering rule"]

A wide range of processing actions can be triggered by a rule. Rule processing continues until all rules have been applied, or until the message is moved to another user or deleted as the result of a rule.You can define multiple rules with the same trigger conditions to have multiple actions applied to the same message -- Mercury will apply them in the order in which they appear in the list. Make sure that any rules containing "Move" or "Delete"actions are the last you define for a particular trigger text, since rule processing on a message stops after these actions.

[/quote]

Email users can be puzzled by size limits because the MIME encoding, which typically uses Base64 adds ~33% overhead – so that a 20MB document on disk exceeds a 25MB file attachment limit.&nbsp;After reading the Mercury help, i think that i found an answer:&nbsp; [quote user="Actions that can be performed by a filtering rule"]&nbsp; <div> A wide range of processing actions can be triggered by a rule. Rule processing continues until all rules have been applied, or until the message is moved to another user or deleted as the result of a rule.You can define multiple rules with the same trigger conditions to have multiple actions applied to the same message -- Mercury will apply them in the order in which they appear in the list. Make sure that any rules containing "Move" or "Delete"actions are the last you define for a particular trigger text, since rule processing on a message stops after these actions. [/quote]</div>

Brian Fluet

posted Jun 19 '15 at 11:54 pm

My approach to controlling rule processing...

Rule1 ... goto label Rule1
Rule2 ... goto label Rule2
Rule3 ... goto label Rule3
Always Exit
Label Rule1
Always send text file
Always copy another user
Always delete
Always Exit
Label Rule2
.
.
.
Always Exit
Label Rule3
.
.
.
Always Exit

The "Always Exit" is not necessary after an "Always Delete" but I feel more comfortable always ending with an "Always Exit" command.

My approach to controlling rule processing...Rule1 ... goto label Rule1 Rule2 ... goto label Rule2 Rule3 ... goto label Rule3 Always Exit Label Rule1 Always send text file Always copy another user Always delete Always Exit Label Rule2 . . . Always Exit Label Rule3 . . . Always ExitThe "Always Exit" is not necessary after an "Always Delete" but I feel more comfortable always ending with an "Always Exit" command.

Greenman

posted Jun 22 '15 at 10:45 am

[quote user="Sellerie"]

Email users can be puzzled by size limits because the MIME encoding, which typically uses Base64 adds ~33% overhead – so that a 20MB document on disk exceeds a 25MB file attachment limit. After reading the Mercury help, i think that i found an answer:

[quote user="Actions that can be performed by a filtering rule"]

A wide range of processing actions can be triggered by a rule. Rule processing continues until all rules have been applied, or until the message is moved to another user or deleted as the result of a rule.You can define multiple rules with the same trigger conditions to have multiple actions applied to the same message -- Mercury will apply them in the order in which they appear in the list. Make sure that any rules containing "Move" or "Delete"actions are the last you define for a particular trigger text, since rule processing on a message stops after these actions.

[/quote]

Thanks, and yes, you are quite correct about the impact that MIME encoding has on a message size. However, as I mentioned in an earlier reply, the message was well below the size limit, and secondly, the message was internal and was not, therefore, subject to outgoing message rules. I can attach a 27MB file to a message addressed to a local user using both their local username and their full @domain address. The MIME encoding increases the message size to 39MB, but it is still delivered.

[quote user="Sellerie"] Email users can be puzzled by size limits because the MIME encoding, which typically uses Base64 adds ~33% overhead – so that a 20MB document on disk exceeds a 25MB file attachment limit.&nbsp;After reading the Mercury help, i think that i found an answer:&nbsp; [quote user="Actions that can be performed by a filtering rule"]&nbsp; <DIV> A wide range of processing actions can be triggered by a rule. Rule processing continues until all rules have been applied, or until the message is moved to another user or deleted as the result of a rule.You can define multiple rules with the same trigger conditions to have multiple actions applied to the same message -- Mercury will apply them in the order in which they appear in the list. Make sure that any rules containing "Move" or "Delete"actions are the last you define for a particular trigger text, since rule processing on a message stops after these actions.[/quote]</DIV> [/quote] Thanks, and yes, you are quite correct about the impact that&nbsp;MIME encoding&nbsp;has &nbsp;on a message size. However, as I&nbsp;mentioned in an earlier reply, the message was well below the size limit, and secondly, the message was internal and was not, therefore,&nbsp;subject to outgoing&nbsp;message rules. I can attach a 27MB file to a message addressed to a&nbsp;local user&nbsp;using both their local username and their full @domain address. The MIME encoding increases the message size to 39MB, but it is still delivered. &nbsp; &nbsp; &nbsp; &nbsp;

Greenman

posted Jun 22 '15 at 10:55 am

[quote user="Brian Fluet"]

My approach to controlling rule processing...

Rule1 ... goto label Rule1
Rule2 ... goto label Rule2
Rule3 ... goto label Rule3
Always Exit
Label Rule1
Always send text file
Always copy another user
Always delete
Always Exit
Label Rule2
.
.
.
Always Exit
Label Rule3
.
.
.
Always Exit

The "Always Exit" is not necessary after an "Always Delete" but I feel more comfortable always ending with an "Always Exit" command.

[/quote]

Thanks, Brian

The size limit rule is applied as part of the Outgoing message filter. The rules are the first in that list and are first because we frequently find that organisations, especially local authority organisations, have size restrictions in place. There are just a couple of rules after these which are designed to copy messages sent by staff working remotely who use Google Apps GMail. Google Apps is configured to send mail via our mail server, and the rule picks up those messages and copies them to their local mail account (otherwise we would not have a record of what was sent via GMail).

If they sent a message that exceeded the size limit it would be deleted and they would receive a notification.

[quote user="Brian Fluet"] My approach to controlling rule processing... Rule1 ... goto label Rule1 Rule2 ... goto label Rule2 Rule3 ... goto label Rule3 Always Exit Label Rule1 Always send text file Always copy another user Always delete Always Exit Label Rule2 . . . Always Exit Label Rule3 . . . Always Exit The "Always Exit" is not necessary after an "Always Delete" but I feel more comfortable always ending with an "Always Exit" command. [/quote] &nbsp; Thanks, Brian The size limit rule is applied as part of the Outgoing message filter. The rules are the first in that list and are first because we frequently find that organisations, especially local authority organisations, have size restrictions in place. There are just a couple of rules after these which are designed to copy messages sent by staff working remotely who use Google Apps GMail.&nbsp;Google Apps is configured to send mail&nbsp;via our mail server,&nbsp;and the rule picks up those messages and copies them to their local mail account (otherwise we would not have a record of what was sent via GMail). If they sent a message that exceeded the size limit it would be deleted and they would receive a notification.

Greenman

posted Jun 22 '15 at 2:21 pm

The kill command must be coming from somewhere, but I have absolutely no idea what has been triggered within Mercury to 'kill' the message. Is there some internal process that causes this to happen? What criteria are being used to 'kill' a message?

Thanks.

The kill command&nbsp;must be coming from somewhere, but I have absolutely no idea what has been triggered within Mercury to 'kill' the message. Is there some internal process that causes this to happen? What criteria are being used to 'kill' a message? Thanks.

Brian Fluet

posted Jun 22 '15 at 2:47 pm

You mention "outgoing rule" a couple of times but not global rules. Just wanting to make sure you know that local messages get processed through global rules.

You mention "outgoing rule" a couple of times but not global rules.&nbsp; Just wanting to make sure you know that local messages get processed through global rules.

Greenman

posted Jun 22 '15 at 3:43 pm

[quote user="Brian Fluet"]You mention "outgoing rule" a couple of times but not global rules. Just wanting to make sure you know that local messages get processed through global rules.
[/quote]

Thanks. Yes - I was aware of this. I have three rules (in the Global Rules list) that Move messages addressed to one account into another. When the move takes place the original message is deleted and I see this in the Mercury console as a 'kill' action, but the message will appear in the other account. All other rules Forward or Copy.

When the moved messages are killed, the new message appears in the other account.

None of the addresses in the distribution list are affected by a Move rule.

[quote user="Brian Fluet"]You mention "outgoing rule" a couple of times but not global rules.&nbsp; Just wanting to make sure you know that local messages get processed through global rules. [/quote] Thanks. Yes - I was aware of this. I have&nbsp;three rules (in the Global Rules list) that Move messages addressed to one account into another. When the move takes place the original message is deleted and I see this in the Mercury console as a 'kill' action, but the message will appear in the other account. All other rules Forward or Copy. When the moved messages are killed, the&nbsp;new message&nbsp;appears in the other account. None of the addresses in the distribution list are affected by a Move rule.

Greenman

posted Jun 23 '15 at 12:12 pm

I just forwarded a message advertising banner Ad space to my account from a different account. Mercury 'killed' it, so my account did not receive it, but it sent another copy to the original recipient (the account I forwarded it from).

This is driving me nuts. What on earth is happening here? I am obviously missing something important. Why are messages being deleted?

I just forwarded a message advertising banner Ad space to my account from a different account. Mercury 'killed' it, so my account did not receive it, but it sent another copy to the original recipient (the account I forwarded it from). This is driving me nuts. What on earth is happening here?&nbsp;I am obviously missing something important.&nbsp;Why are messages being deleted?

Brian Fluet

posted Jun 23 '15 at 3:06 pm

It is reassuring that someone else has experienced the problem; I thought I was the only one. I am happy to assist in any way that I can to help identify the cause but we obviously need more help.

FWIW, I started running two instances as a workaround thinking it would only be temporary. That was many years ago. I currently run Mercury C, D, & I in one instance and Mercury C & S in the other (both still v4.74). They run on a dedicated PC. I don't run them as a service so have each GUI configured to occupy half of the screen with a child window open for each module. It is a functional setup but that second instance should not be needed.

It is reassuring that someone else has experienced the problem;&nbsp; I thought I was the only one.&nbsp; I am happy to assist in any way that I can to help identify the cause but we obviously need more help. FWIW,&nbsp; I started running two instances as a workaround thinking it would only be temporary.&nbsp; That was many years ago.&nbsp; I currently run Mercury C, D, &amp; I in one instance and Mercury C &amp; S in the other (both still v4.74).&nbsp; They run on a dedicated PC.&nbsp; I don't run them as a service so have each GUI configured to occupy half of the screen with a child window open for each module.&nbsp; It is a functional setup but that second instance should not be needed.

Rolf Lindby

posted Jun 24 '15 at 1:04 am

[quote user="Greenman"]

I just forwarded a message advertising banner Ad space to my account from a different account. Mercury 'killed' it, so my account did not receive it, but it sent another copy to the original recipient (the account I forwarded it from).

This is driving me nuts. What on earth is happening here? I am obviously missing something important. Why are messages being deleted?

[/quote]

If you could provide the CNM file, or actually just all headers, from the message being forwarded we could have a look at it.

[quote user="Greenman"]I just forwarded a message advertising banner Ad space to my account from a different account. Mercury 'killed' it, so my account did not receive it, but it sent another copy to the original recipient (the account I forwarded it from). This is driving me nuts. What on earth is happening here?&nbsp;I am obviously missing something important.&nbsp;Why are messages being deleted?[/quote]If you could provide the CNM file, or&nbsp;actually&nbsp;just all headers, from the message being forwarded we could have a look at it.

Greenman

posted Jun 24 '15 at 11:06 am

[quote user="Rolf Lindby"][quote user="Greenman"]

I just forwarded a message advertising banner Ad space to my account from a different account. Mercury 'killed' it, so my account did not receive it, but it sent another copy to the original recipient (the account I forwarded it from).

This is driving me nuts. What on earth is happening here? I am obviously missing something important. Why are messages being deleted?

[/quote]

If you could provide the CNM file, or actually just all headers, from the message being forwarded we could have a look at it.

[/quote]

Hi, Rolf

Thanks a lot.

I've changed our domain names to our-domain1 and our-domain2.
My address has been changed to greenman and the person who resent it has been changed to SendingRecipient.
MRsP is the account that originally received the message. She has two accounts (MrsP and SendingRecipient) and MrsP has a filtering rule that sends all received messages to SendingRecipient.

If you would like to see the original headers without these edits let me know and I will send them to you in a PM

Resent-from: "Sending Recipient" <SendingRecipient@our-domain1.co.uk>
Resent-to: greenman@our-domain2.org
Resent-date: Tue, 23 Jun 2015 10:03:26 +0100
Return-path: <SRS0=TwbF=HB=bounce.mailsendlink.com=bounce-33490112-93884-20126480-701396@emailfirewall.spamina.com>
Received: from srv20253.emailfirewall.spamina.com (92.54.22.4) by our-domain1.co.uk (Mercury/32 v4.74) with ESMTP ID

MG003193;
 23 Jun 2015 09:49:22 +0100
Received: from [123.103.242.62] (helo=mta005.mailsendlink.com)
by srv20253.emailfirewall.spamina.com with esmtp (Exim 4.80)
(envelope-from <bounce-33490112-93884-20126480-701396@bounce.mailsendlink.com>)
id 1Z7JtP-0005li-IA
for MrsP@our-domain1.co.uk; Tue, 23 Jun 2015 10:49:21 +0200
X-Envelope-From: bounce-33490112-93884-20126480-701396@bounce.mailsendlink.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; s=key0; d=mailsendlink.com;
h=Date:To:From:Reply-to:Subject:Message-ID:List-Unsubscribe:MIME-Version:Content-Type;
bh=tBgqyGO1DasTxHuuCEEPuwa6HV8wbyZztjkXroS4FVk=;
b=W57Jmxfbwe0a4whYd9muGi7oklTI/8iI7lzYBJNUjgMyB6irPJ6hVjK0K0Mixz42gcBpN7MWBrPh
 dwCc67wT4jp+FfBcJ2ZdA4CSYq5mJ/T35SKreihCzzwVWM8yAzNkLo15qYlvvf2cWqXxQ/Zj9kpZ
 6fak5YeTavh6PT2TNd8=
Date: Tue, 23 Jun 2015 08:48:22 +0000
To: "MrsP@our-domain1.co.uk" <MrsP@our-domain1.co.uk>
From: Amy Wood / Web Windows <amy.wood@webwindows.co.uk>
Reply-to: Amy Wood / Web Windows <amy.wood@webwindows.co.uk>
Subject: =?utf-8?Q?RE:_Cut_Price_Daily_Mail_Banner_Ads_...28_days_=C2=A3625?=
Message-ID: <7bba5cbb5418741e47d074bad38b8b7a@mailsendlink.com>
X-Priority: 3
X-Mailer: mailsendlink.com
X-Complaints-To: complaints@mailsendlink.com
List-Unsubscribe: <mailto:us-3jfz-rs-14k-24wb-33h5-rs@bounce.mailsendlink.com>, <http://app.mailsendlink.com/u.php?

p=3jfz/rs/14k/24wb/33h5/rs>
X-MessageID: 3jfz-14k-c2FyYWgucHJpdGNoYXJkQGFwc2FyY2hhZW9sb2d5LmNvLnVr-24wb-3fa-rs
X-Report-Abuse: <http://app.mailsendlink.com/report_abuse.php?mid=3jfz-14k-

c2FyYWgucHJpdGNoYXJkQGFwc2FyY2hhZW9sb2d5LmNvLnVr-24wb-3fa-rs>
X-CampaignID: 164167
X-GroupID: 30
X-SubscriberID: 460
x-job: 3438-164167
X-Campaign: True
X-Type: Campaign Email
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="b1_7bba5cbb5418741e47d074bad38b8b7a"
X-CTCH-IPCLASS: T3
X-CTCH-RefID: str=0001.0A0B0203.55891D90.0213,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-SPF-Received: 2
X-Spamina-Bogosity: Unsure
X-Spamina-Spam-Score: 1.6 (+)
X-Spamina-Spam-Report: Content analysis details:   (1.6 points)
pts rule name              description
---- ---------------------- --------------------------------------------------
0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was blocked.
                             See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: our-domain1.co.uk]
-0.0 SPF_PASS               SPF: sender matches SPF record
0.0 HTML_MESSAGE           BODY: HTML included in message
0.8 BAYES_50               BODY: Bayes spam probability is 40 to 60%
                             [score: 0.4651]
0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
0.8 RDNS_NONE              Delivered to internal network by a host with no rDNS
X-Spamina-History: list
X-Spamina-Service-Type: pyme
X-PMFLAGS: 570950080 0 1 JL5JU1S3.CNM

--b1_7bba5cbb5418741e47d074bad38b8b7a
Content-Type: text/plain; charset = "utf-8"
Content-Transfer-Encoding: 8bit

[quote user="Rolf Lindby"][quote user="Greenman"] I just forwarded a message advertising banner Ad space to my account from a different account. Mercury 'killed' it, so my account did not receive it, but it sent another copy to the original recipient (the account I forwarded it from). This is driving me nuts. What on earth is happening here?&nbsp;I am obviously missing something important.&nbsp;Why are messages being deleted? [/quote] If you could provide the CNM file, or&nbsp;actually&nbsp;just all headers, from the message being forwarded we could have a look at it. [/quote] Hi, Rolf Thanks a lot. I've changed our domain names to our-domain1 and our-domain2. My address has been changed to greenman and the person who resent it has been&nbsp;changed to SendingRecipient. MRsP is the account that originally received the message. She has two accounts (MrsP and SendingRecipient)&nbsp;and MrsP has a filtering rule that sends all received messages to SendingRecipient. If you would like to see the original headers without these edits let me know and I will send them to you in a PM Resent-from: "Sending Recipient" &lt;SendingRecipient@our-domain1.co.uk&gt; Resent-to: greenman@our-domain2.org Resent-date: Tue, 23 Jun 2015 10:03:26 +0100 Return-path: &lt;SRS0=TwbF=HB=bounce.mailsendlink.com=bounce-33490112-93884-20126480-701396@emailfirewall.spamina.com&gt; Received: from srv20253.emailfirewall.spamina.com (92.54.22.4) by our-domain1.co.uk (Mercury/32 v4.74) with ESMTP ID MG003193; &nbsp;&nbsp; 23 Jun 2015 09:49:22 +0100 Received: from [123.103.242.62] (helo=mta005.mailsendlink.com) &nbsp;by srv20253.emailfirewall.spamina.com with esmtp (Exim 4.80) &nbsp;(envelope-from &lt;bounce-33490112-93884-20126480-701396@bounce.mailsendlink.com&gt;) &nbsp;id 1Z7JtP-0005li-IA &nbsp;for MrsP@our-domain1.co.uk; Tue, 23 Jun 2015 10:49:21 +0200 X-Envelope-From: bounce-33490112-93884-20126480-701396@bounce.mailsendlink.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; s=key0; d=mailsendlink.com; &nbsp;h=Date:To:From:Reply-to:Subject:Message-ID:List-Unsubscribe:MIME-Version:Content-Type; &nbsp;bh=tBgqyGO1DasTxHuuCEEPuwa6HV8wbyZztjkXroS4FVk=; &nbsp;b=W57Jmxfbwe0a4whYd9muGi7oklTI/8iI7lzYBJNUjgMyB6irPJ6hVjK0K0Mixz42gcBpN7MWBrPh &nbsp;&nbsp; dwCc67wT4jp+FfBcJ2ZdA4CSYq5mJ/T35SKreihCzzwVWM8yAzNkLo15qYlvvf2cWqXxQ/Zj9kpZ &nbsp;&nbsp; 6fak5YeTavh6PT2TNd8= Date: Tue, 23 Jun 2015 08:48:22 +0000 To: "MrsP@our-domain1.co.uk" &lt;MrsP@our-domain1.co.uk&gt; From: Amy Wood / Web Windows &lt;amy.wood@webwindows.co.uk&gt; Reply-to: Amy Wood / Web Windows &lt;amy.wood@webwindows.co.uk&gt; Subject: =?utf-8?Q?RE:_Cut_Price_Daily_Mail_Banner_Ads_...28_days_=C2=A3625?= Message-ID: &lt;7bba5cbb5418741e47d074bad38b8b7a@mailsendlink.com&gt; X-Priority: 3 X-Mailer: mailsendlink.com X-Complaints-To: complaints@mailsendlink.com List-Unsubscribe: &lt;mailto:us-3jfz-rs-14k-24wb-33h5-rs@bounce.mailsendlink.com&gt;, &lt;http://app.mailsendlink.com/u.php? p=3jfz/rs/14k/24wb/33h5/rs&gt; X-MessageID: 3jfz-14k-c2FyYWgucHJpdGNoYXJkQGFwc2FyY2hhZW9sb2d5LmNvLnVr-24wb-3fa-rs X-Report-Abuse: &lt;http://app.mailsendlink.com/report_abuse.php?mid=3jfz-14k- c2FyYWgucHJpdGNoYXJkQGFwc2FyY2hhZW9sb2d5LmNvLnVr-24wb-3fa-rs&gt; X-CampaignID: 164167 X-GroupID: 30 X-SubscriberID: 460 x-job: 3438-164167 X-Campaign: True X-Type: Campaign Email Precedence: bulk MIME-Version: 1.0 Content-Type: multipart/alternative; &nbsp;boundary="b1_7bba5cbb5418741e47d074bad38b8b7a" X-CTCH-IPCLASS: T3 X-CTCH-RefID: str=0001.0A0B0203.55891D90.0213,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-SPF-Received: 2 X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: 1.6 (+) X-Spamina-Spam-Report: Content analysis details:&nbsp;&nbsp; (1.6 points) &nbsp; pts rule name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; description &nbsp;---- ---------------------- -------------------------------------------------- &nbsp; 0.0 URIBL_BLOCKED&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ADMINISTRATOR NOTICE: The query to URIBL was blocked. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; See &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for more information. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [URIs: our-domain1.co.uk] &nbsp;-0.0 SPF_PASS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SPF: sender matches SPF record &nbsp; 0.0 HTML_MESSAGE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BODY: HTML included in message &nbsp; 0.8 BAYES_50&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BODY: Bayes spam probability is 40 to 60% &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [score: 0.4651] &nbsp; 0.1 DKIM_SIGNED&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Message has a DKIM or DK signature, not necessarily valid &nbsp;-0.1 DKIM_VALID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Message has at least one valid DKIM or DK signature &nbsp; 0.8 RDNS_NONE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Delivered to internal network by a host with no rDNS X-Spamina-History: list X-Spamina-Service-Type: pyme X-PMFLAGS: 570950080 0 1 JL5JU1S3.CNM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --b1_7bba5cbb5418741e47d074bad38b8b7a Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit

Rolf Lindby

posted Jun 25 '15 at 3:09 am

Could you please zip it and send to me separately, just to make sure there are no extra blank lines inserted!

Could you please zip it and send to me separately, just to make sure there are no extra blank lines inserted!

Greenman

posted Jun 25 '15 at 10:45 am

Hi, Rolf

I have sent the entire CNM to you. Please check your PM for the link.

Thanks

Hi, Rolf I have sent the entire CNM to you. Please check your PM for the link. Thanks

Related Topics

Pending draft

Confirm move posts

Insufficient permissions

Select a different topic

Edit history