The recipient address <br><br><br><div class="gmail_quote">On Tue, Apr 28, 2009 at 2:04 PM, <span dir="ltr"><<a href="mailto:mailscanner-request@lists.mailscanner.info">mailscanner-request@lists.mailscanner.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Send MailScanner mailing list submissions to<br>
<a href="mailto:mailscanner@lists.mailscanner.info">mailscanner@lists.mailscanner.info</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.mailscanner.info/mailman/listinfo/mailscanner" target="_blank">http://lists.mailscanner.info/mailman/listinfo/mailscanner</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:mailscanner-request@lists.mailscanner.info">mailscanner-request@lists.mailscanner.info</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:mailscanner-owner@lists.mailscanner.info">mailscanner-owner@lists.mailscanner.info</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of MailScanner digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: OT: Bounced Email (Mark Sapiro)<br>
2. attachments block (Khaled Hussein)<br>
3. Re: attachments block (Julian Field)<br>
4. Slooow MailScanner = bitdefender?? (Nigel Kendrick)<br>
5. Re: Maximum Processing Attempts (Kai Schaetzl)<br>
6. Re: OT: Bounced Email (Kai Schaetzl)<br>
7. Re: Preventing multple signatures in email conversation?<br>
(Kai Schaetzl)<br>
8. Re: Maximum Processing Attempts (Matt)<br>
9. Re: Maximum Processing Attempts (David Lee)<br>
10. Re: Maximum Processing Attempts (Julian Field)<br>
11. 4.76.22 (Julian Field)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Mon, 27 Apr 2009 16:07:32 -0700<br>
From: Mark Sapiro <<a href="mailto:mark@msapiro.net">mark@msapiro.net</a>><br>
Subject: Re: OT: Bounced Email<br>
To: MailScanner discussion <<a href="mailto:mailscanner@lists.mailscanner.info">mailscanner@lists.mailscanner.info</a>><br>
Message-ID: <20090427230732.GA3304@msapiro><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Mon, Apr 27, 2009 at 07:02:56PM +0100, Drew Marshall wrote:<br>
> On 27 Apr 2009, at 16:44, Johnny Stork wrote:<br>
><br>
> >Hmm, ok, but what about these occaisional "probes" I get from a<br>
> >couple lists?<br>
> ><br>
> >Hi! This is the ezmlm program. I'm managing the<br>
> ><a href="mailto:users@spamassassin.apache.org">users@spamassassin.apache.org</a> mailing list.<br>
> ><br>
> ><br>
> >Messages to you from the users mailing list seem to<br>
> >have been bouncing. I sent you a warning message, but it bounced.<br>
> >I've attached a copy of the bounce message.<br>
><br>
> Almost certainly generated because your address generated some form of<br>
> 4xx error message that was returned to the list server. Do you have<br>
> grey listing or some form of recipient checking going on? Either of<br>
> these could cause this sort of probe.<br>
<br>
<br>
Again, I don't know about ezmlm, but bounces with 4xx status to a<br>
Mailman list are ignored.<br>
<br>
--<br>
Mark Sapiro mark at msapiro net The highway is for gamblers,<br>
San Francisco Bay Area, California better use your sense - B. Dylan<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 28 Apr 2009 09:21:07 +0300<br>
From: Khaled Hussein <<a href="mailto:khaled.jamil@gmail.com">khaled.jamil@gmail.com</a>><br>
Subject: attachments block<br>
To: <a href="mailto:mailscanner@lists.mailscanner.info">mailscanner@lists.mailscanner.info</a><br>
Message-ID:<br>
<<a href="mailto:819715630904272321uc267b11m3efe2200d31b89dc@mail.gmail.com">819715630904272321uc267b11m3efe2200d31b89dc@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi All,<br>
<br>
i added a rule in my filename.rulse.conf file to deny attachments start with<br>
DSL (all of them viagra pics), it works fine but i want to prevent<br>
mailscanner from sending the report to the email address that this file has<br>
been blocked, how can i do this or if ther is another way to block these<br>
messages<br>
<br>
<br>
Thanks<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.mailscanner.info/pipermail/mailscanner/attachments/20090428/f6a9d697/attachment-0001.html" target="_blank">http://lists.mailscanner.info/pipermail/mailscanner/attachments/20090428/f6a9d697/attachment-0001.html</a><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 28 Apr 2009 08:29:45 +0100<br>
From: Julian Field <<a href="mailto:MailScanner@ecs.soton.ac.uk">MailScanner@ecs.soton.ac.uk</a>><br>
Subject: Re: attachments block<br>
To: MailScanner discussion <<a href="mailto:mailscanner@lists.mailscanner.info">mailscanner@lists.mailscanner.info</a>><br>
Message-ID:<br>
<EMEW3|a43f45235357bfbb5ee0809627107a3cl3R8Ys0bMailScanner|<a href="http://ecs.soton.ac.uk" target="_blank">ecs.soton.ac.uk</a>|<a href="mailto:040500@ecs.soton.ac.uk">040500@ecs.soton.ac.uk</a>><br>
<br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
<br>
<br>
On 28/04/2009 07:21, Khaled Hussein wrote:<br>
> Hi All,<br>
><br>
> i added a rule in my filename.rulse.conf file to deny attachments<br>
> start with DSL (all of them viagra pics), it works fine but i want to<br>
> prevent mailscanner from sending the report to the email address<br>
Which email address? The sender or the recipient?<br>
> that this file has been blocked, how can i do this or if ther is<br>
> another way to block these messages<br>
><br>
><br>
> Thanks<br>
><br>
><br>
<br>
Jules<br>
<br>
--<br>
Julian Field MEng CITP CEng<br>
<a href="http://www.MailScanner.info" target="_blank">www.MailScanner.info</a><br>
Buy the MailScanner book at <a href="http://www.MailScanner.info/store" target="_blank">www.MailScanner.info/store</a><br>
<br>
MailScanner customisation, or any advanced system administration help?<br>
Contact me at Jules@Jules.FM<br>
<br>
PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654<br>
PGP public key: <a href="http://www.jules.fm/julesfm.asc" target="_blank">http://www.jules.fm/julesfm.asc</a><br>
Follow me at <a href="http://twitter.com/JulesFM" target="_blank">twitter.com/JulesFM</a><br>
<br>
<br>
--<br>
This message has been scanned for viruses and<br>
dangerous content by MailScanner, and is<br>
believed to be clean.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 28 Apr 2009 10:27:20 +0100<br>
From: "Nigel Kendrick" <<a href="mailto:support-lists@petdoctors.co.uk">support-lists@petdoctors.co.uk</a>><br>
Subject: Slooow MailScanner = bitdefender??<br>
To: "'MailScanner discussion'" <<a href="mailto:mailscanner@lists.mailscanner.info">mailscanner@lists.mailscanner.info</a>><br>
Message-ID: <4D373C90AFA24050BDABCAC9CDD9A525@SUPPORT01V><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Morning,<br>
<br>
I have a P4 3GHz server running MailScanner 4.75.11 that has has been<br>
working fine, but over the last few days it has taken to slowing down<br>
dramatically and the CPU load hits 13+<br>
<br>
Admittedly the server could do with a bit more RAM (it has 768MB), but it<br>
has worked fine for several years and the load is very small (<300 emails a<br>
day).<br>
<br>
A quick look at htop shows that the bitdefender update process seems to run<br>
'forever' and eats up >500MB and then the server goes into swap city and<br>
almost grinds to a halt.<br>
<br>
The upgrade from 4.69.? happened around the same time as the slow down so<br>
has something changed that might have caused this? I guess something may<br>
have just tipped the server over a critical RAM requirement so I am going to<br>
fit some more (1.5GB) but any other thoughts appreciated as other servers<br>
upgraded at the same time (fitted with more RAM) have not experienced the<br>
slow down.<br>
<br>
Thanks<br>
<br>
Nigel Kendrick<br>
<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.mailscanner.info/pipermail/mailscanner/attachments/20090428/370a2596/attachment-0001.html" target="_blank">http://lists.mailscanner.info/pipermail/mailscanner/attachments/20090428/370a2596/attachment-0001.html</a><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Tue, 28 Apr 2009 11:31:19 +0200<br>
From: Kai Schaetzl <<a href="mailto:maillists@conactive.com">maillists@conactive.com</a>><br>
Subject: Re: Maximum Processing Attempts<br>
To: <a href="mailto:mailscanner@lists.mailscanner.info">mailscanner@lists.mailscanner.info</a><br>
Message-ID: <<a href="mailto:VA.000037e4.008a2125@news.conactive.com">VA.000037e4.008a2125@news.conactive.com</a>><br>
Content-Type: text/plain; charset=iso-8859-1<br>
<br>
Julian Field wrote on Mon, 27 Apr 2009 22:40:16 +0100:<br>
<br>
> Should I leave it switched on by default, so heavily loaded sites can<br>
> switch it off to gain that extra bit of performance, at the cost of a<br>
> potential reliability hit?<br>
<br>
>From the past discussion I think it is mainly those heavy-traffic sites<br>
that would benefit from it. I think we had exactly two folks mentioning a<br>
problem with occasional messages getting not processed somehow. Both with<br>
high-volume sites. So, the majority does not need this feature to be on.<br>
On the other hand, exactly those people who need it will also be hit most<br>
by the performance hit (as small as it may be).<br>
Unfortunately none of them participated in the recent discussion.<br>
<br>
Kai<br>
<br>
--<br>
Kai Schätzl, Berlin, Germany<br>
Get your web at Conactive Internet Services: <a href="http://www.conactive.com" target="_blank">http://www.conactive.com</a><br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Tue, 28 Apr 2009 11:31:19 +0200<br>
From: Kai Schaetzl <<a href="mailto:maillists@conactive.com">maillists@conactive.com</a>><br>
Subject: Re: OT: Bounced Email<br>
To: <a href="mailto:mailscanner@lists.mailscanner.info">mailscanner@lists.mailscanner.info</a><br>
Message-ID: <<a href="mailto:VA.000037e3.008a2125@news.conactive.com">VA.000037e3.008a2125@news.conactive.com</a>><br>
Content-Type: text/plain; charset=iso-8859-1<br>
<br>
Drew Marshall wrote on Mon, 27 Apr 2009 18:57:35 +0100:<br>
<br>
> This one should be fine<br>
<br>
Yes, it's back to normal now.<br>
<br>
Kai<br>
<br>
--<br>
Kai Schätzl, Berlin, Germany<br>
Get your web at Conactive Internet Services: <a href="http://www.conactive.com" target="_blank">http://www.conactive.com</a><br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Tue, 28 Apr 2009 11:31:18 +0200<br>
From: Kai Schaetzl <<a href="mailto:maillists@conactive.com">maillists@conactive.com</a>><br>
Subject: Re: Preventing multple signatures in email conversation?<br>
To: <a href="mailto:mailscanner@lists.mailscanner.info">mailscanner@lists.mailscanner.info</a><br>
Message-ID: <<a href="mailto:VA.000037e2.008a2115@news.conactive.com">VA.000037e2.008a2115@news.conactive.com</a>><br>
Content-Type: text/plain; charset=iso-8859-1<br>
<br>
Kevin Miller wrote on Mon, 27 Apr 2009 08:37:00 -0800:<br>
<br>
> Yes - change the above "dash dash" to "dash dash space".<br>
<br>
look again. The separator is correct. It's a QP message.<br>
<br>
Kai<br>
<br>
--<br>
Kai Schätzl, Berlin, Germany<br>
Get your web at Conactive Internet Services: <a href="http://www.conactive.com" target="_blank">http://www.conactive.com</a><br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Tue, 28 Apr 2009 11:03:49 +0100<br>
From: Matt <<a href="mailto:spamlists@coders.co.uk">spamlists@coders.co.uk</a>><br>
Subject: Re: Maximum Processing Attempts<br>
To: MailScanner discussion <<a href="mailto:mailscanner@lists.mailscanner.info">mailscanner@lists.mailscanner.info</a>><br>
Message-ID: <<a href="mailto:49F6D485.2020501@coders.co.uk">49F6D485.2020501@coders.co.uk</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
Kai Schaetzl wrote:<br>
> >From the past discussion I think it is mainly those heavy-traffic sites<br>
> that would benefit from it. I think we had exactly two folks mentioning a<br>
> problem with occasional messages getting not processed somehow. Both with<br>
> high-volume sites. So, the majority does not need this feature to be on.<br>
> On the other hand, exactly those people who need it will also be hit most<br>
> by the performance hit (as small as it may be).<br>
><br>
> Unfortunately none of them participated in the recent discussion.<br>
><br>
<br>
I run a high volume service and up until recently I have had nothing to<br>
add as we have have only been affected by this issue once. However, in<br>
the last couple of weeks we have had this happen to two of servers.<br>
Within in 20 minutes the queues had grown to unexceptable levels and the<br>
LA on the box jumped hugely. It took me over an hour to track down<br>
which message caused the issue (as an aside - adding the message back in<br>
to the processing queue about an hour later and it went through fine!).<br>
<br>
I for one would have accepted the the tiny hit a few SQLite queries per<br>
message would have caused had the code been avalible then. I hope to<br>
have the code in production by the end of the week<br>
<br>
<br>
matt<br>
<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Tue, 28 Apr 2009 11:06:33 +0100 (BST)<br>
From: David Lee <<a href="mailto:t.d.lee@durham.ac.uk">t.d.lee@durham.ac.uk</a>><br>
Subject: Re: Maximum Processing Attempts<br>
To: MailScanner discussion <<a href="mailto:mailscanner@lists.mailscanner.info">mailscanner@lists.mailscanner.info</a>><br>
Message-ID: <<a href="mailto:alpine.LFD.2.00.0904281049160.4895@claus.dur.ac.uk">alpine.LFD.2.00.0904281049160.4895@claus.dur.ac.uk</a>><br>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed<br>
<br>
On Tue, 28 Apr 2009, Kai Schaetzl wrote:<br>
<br>
> Julian Field wrote on Mon, 27 Apr 2009 22:40:16 +0100:<br>
><br>
>> Should I leave it switched on by default, so heavily loaded sites can<br>
>> switch it off to gain that extra bit of performance, at the cost of a<br>
>> potential reliability hit?<br>
><br>
>> From the past discussion I think it is mainly those heavy-traffic sites<br>
> that would benefit from it. I think we had exactly two folks mentioning a<br>
> problem with occasional messages getting not processed somehow. Both with<br>
> high-volume sites. So, the majority does not need this feature to be on.<br>
> On the other hand, exactly those people who need it will also be hit most<br>
> by the performance hit (as small as it may be).<br>
> Unfortunately none of them participated in the recent discussion.<br>
<br>
Kai, the feature isn't primarily about "occasional messages getting not<br>
processed somehow". Rather it is about the severe knock-on effects that<br>
can have.<br>
<br>
(Reminder: If there is some characteristic with a number of emails that<br>
causes perl/MS to crash, then that causes the whole "batch", including<br>
many innocent emails, not to get processed. Subsequent runs keep tripping<br>
over the same thing. If there are a few more such rogue emails than there<br>
are MS children, then almost all the innocent email gets held up<br>
indefinitely. Such rogue emails are typically spam, and so there tend to<br>
be many instances of it. Yes, the problem is rare. But when it hits, it<br>
can be very severe: all email blocked; massive inbound queue build-up;<br>
load average through the roof.)<br>
<br>
We've been running it in production ever since Julian first put it into a<br>
beta. (I was honour-bound to do so; I had suggested it!) I haven't<br>
noticed a performance impact.<br>
<br>
<br>
My vote is to leave it on.<br>
<br>
Email sys.admins have varying ability. When this problem hits, even<br>
experienced sys.admins struggle. (Been there; more than once.) The less<br>
experienced would struggle even more. The default of this option should<br>
be biased in favour of the inexperienced sys.admin. So the default (I<br>
suggest) should be "on". (A sys.admin. who is experienced enough to know<br>
they don't need it is, by definition, experienced enough to find their way<br>
to switching it off.)<br>
<br>
Hope that helps.<br>
<br>
--<br>
<br>
: David Lee I.T. Service :<br>
: Senior Systems Programmer Computer Centre :<br>
: UNIX Team Leader Durham University :<br>
: South Road :<br>
: <a href="http://www.dur.ac.uk/t.d.lee/" target="_blank">http://www.dur.ac.uk/t.d.lee/</a> Durham DH1 3LE :<br>
: Phone: +44 191 334 2752 U.K. :<br>
<br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Tue, 28 Apr 2009 11:52:26 +0100<br>
From: Julian Field <<a href="mailto:MailScanner@ecs.soton.ac.uk">MailScanner@ecs.soton.ac.uk</a>><br>
Subject: Re: Maximum Processing Attempts<br>
To: MailScanner discussion <<a href="mailto:mailscanner@lists.mailscanner.info">mailscanner@lists.mailscanner.info</a>><br>
Message-ID:<br>
<EMEW3|5c1aa48b84f5385eaf6d82f42124e8dal3RBqm0bMailScanner|<a href="http://ecs.soton.ac.uk" target="_blank">ecs.soton.ac.uk</a>|<a href="mailto:000808@ecs.soton.ac.uk">000808@ecs.soton.ac.uk</a>><br>
<br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
<br>
<br>
On 28/04/2009 11:06, David Lee wrote:<br>
> On Tue, 28 Apr 2009, Kai Schaetzl wrote:<br>
><br>
>> Julian Field wrote on Mon, 27 Apr 2009 22:40:16 +0100:<br>
>><br>
>>> Should I leave it switched on by default, so heavily loaded sites can<br>
>>> switch it off to gain that extra bit of performance, at the cost of a<br>
>>> potential reliability hit?<br>
>><br>
>>> From the past discussion I think it is mainly those heavy-traffic sites<br>
>> that would benefit from it. I think we had exactly two folks<br>
>> mentioning a<br>
>> problem with occasional messages getting not processed somehow. Both<br>
>> with<br>
>> high-volume sites. So, the majority does not need this feature to be on.<br>
>> On the other hand, exactly those people who need it will also be hit<br>
>> most<br>
>> by the performance hit (as small as it may be).<br>
>> Unfortunately none of them participated in the recent discussion.<br>
><br>
> Kai, the feature isn't primarily about "occasional messages getting<br>
> not processed somehow". Rather it is about the severe knock-on<br>
> effects that can have.<br>
><br>
> (Reminder: If there is some characteristic with a number of emails<br>
> that causes perl/MS to crash, then that causes the whole "batch",<br>
> including many innocent emails, not to get processed. Subsequent runs<br>
> keep tripping over the same thing. If there are a few more such rogue<br>
> emails than there are MS children, then almost all the innocent email<br>
> gets held up indefinitely. Such rogue emails are typically spam, and<br>
> so there tend to be many instances of it. Yes, the problem is rare.<br>
> But when it hits, it can be very severe: all email blocked; massive<br>
> inbound queue build-up; load average through the roof.)<br>
><br>
> We've been running it in production ever since Julian first put it<br>
> into a beta. (I was honour-bound to do so; I had suggested it!) I<br>
> haven't noticed a performance impact.<br>
><br>
><br>
> My vote is to leave it on.<br>
><br>
> Email sys.admins have varying ability. When this problem hits, even<br>
> experienced sys.admins struggle. (Been there; more than once.) The<br>
> less experienced would struggle even more. The default of this option<br>
> should be biased in favour of the inexperienced sys.admin. So the<br>
> default (I suggest) should be "on". (A sys.admin. who is experienced<br>
> enough to know they don't need it is, by definition, experienced<br>
> enough to find their way to switching it off.)<br>
><br>
I am convinced by these arguments. I have improved the code since the<br>
last beta, so that it pre-prepares all the SQL statements once when the<br>
database is opened, so the SQL code should be even faster than it was. I<br>
have also switched off the fsync() call that was done at the end of<br>
every database write operation, so that should speed it up too.<br>
<br>
I will release a new beta right now for you to test what is hopefully<br>
the final version of the code, and the feature will remain enabled in<br>
the production stable release.<br>
<br>
Those who know enough that they can dig themselves out of the hole<br>
without the assistance of this feature can switch it off.<br>
<br>
Jules<br>
<br>
--<br>
Julian Field MEng CITP CEng<br>
<a href="http://www.MailScanner.info" target="_blank">www.MailScanner.info</a><br>
Buy the MailScanner book at <a href="http://www.MailScanner.info/store" target="_blank">www.MailScanner.info/store</a><br>
<br>
Need help customising MailScanner?<br>
Contact me!<br>
Need help fixing or optimising your systems?<br>
Contact me!<br>
Need help getting you started solving new requirements from your boss?<br>
Contact me!<br>
<br>
PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654<br>
Follow me at <a href="http://twitter.com/JulesFM" target="_blank">twitter.com/JulesFM</a> and <a href="http://twitter.com/MailScanner" target="_blank">twitter.com/MailScanner</a><br>
<br>
<br>
--<br>
This message has been scanned for viruses and<br>
dangerous content by MailScanner, and is<br>
believed to be clean.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Tue, 28 Apr 2009 11:56:21 +0100<br>
From: Julian Field <<a href="mailto:MailScanner@ecs.soton.ac.uk">MailScanner@ecs.soton.ac.uk</a>><br>
Subject: 4.76.22<br>
To: MailScanner discussion <<a href="mailto:mailscanner@lists.mailscanner.info">mailscanner@lists.mailscanner.info</a>><br>
Message-ID:<br>
<EMEW3|1b07929de9ff07b93e4596ab6f3498bel3RBuU0bMailScanner|<a href="http://ecs.soton.ac.uk" target="_blank">ecs.soton.ac.uk</a>|<a href="mailto:020809@ecs.soton.ac.uk">020809@ecs.soton.ac.uk</a>><br>
<br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
I have just released a new beta, this will be one of the last before the<br>
next stable release.<br>
Please test it, as I have optimised the processing-messages database<br>
code, and fixed one or two little bugs. The Change Log will tell you all<br>
the details.<br>
<br>
Download as usual from <a href="http://www.mailscanner.info" target="_blank">www.mailscanner.info</a>.<br>
<br>
Thanks!<br>
<br>
Jules<br>
<br>
--<br>
Julian Field MEng CITP CEng<br>
<a href="http://www.MailScanner.info" target="_blank">www.MailScanner.info</a><br>
Buy the MailScanner book at <a href="http://www.MailScanner.info/store" target="_blank">www.MailScanner.info/store</a><br>
<br>
Need help customising MailScanner?<br>
Contact me!<br>
Need help fixing or optimising your systems?<br>
Contact me!<br>
Need help getting you started solving new requirements from your boss?<br>
Contact me!<br>
<br>
PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654<br>
Follow me at <a href="http://twitter.com/JulesFM" target="_blank">twitter.com/JulesFM</a> and <a href="http://twitter.com/MailScanner" target="_blank">twitter.com/MailScanner</a><br>
<br>
<br>
--<br>
This message has been scanned for viruses and<br>
dangerous content by MailScanner, and is<br>
believed to be clean.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
--<br>
MailScanner mailing list<br>
<a href="mailto:mailscanner@lists.mailscanner.info">mailscanner@lists.mailscanner.info</a><br>
<a href="http://lists.mailscanner.info/mailman/listinfo/mailscanner" target="_blank">http://lists.mailscanner.info/mailman/listinfo/mailscanner</a><br>
<br>
Before posting, read the Wiki (<a href="http://wiki.mailscanner.info/" target="_blank">http://wiki.mailscanner.info/</a>).<br>
<br>
Support MailScanner development - buy the book off the website!<br>
<br>
<br>
End of MailScanner Digest, Vol 40, Issue 38<br>
*******************************************<br>
</blockquote></div><br><br clear="all"><br>-- <br>Best Regards<br>==================<br>Khaled Hussein<br><a href="mailto:khaled.jamil@gmail.com">khaled.jamil@gmail.com</a><br>Tulkarem - Palestine<br>==================<br>