[sniffer] Re: What is your oldest production CPU?

[eric]

Under Hyper-V using 3rd generation and the most recent 4th generation Xeon 
processors the PROCESSOR_IDENTIFIER environment variable is set to: Intel64 
Family 6 Model nn Stepping n, Genuine Intel






Sent using SmarterSync Over-The-Air sync for iPad, iPhone, BlackBerry and 
other SmartPhones.  May use speech to text.  If something seems odd please 
don't hesitate to ask for clarification.  E.&O.E.

> On Dec 27, 2013, at 1:00 PM, Pete McNeil  
wrote:
> 
>> On 2013-12-27 15:45, Matt wrote:
>> Intel 5400 series Xeon here.  But don't forget virtualization.  I'm not 
sure what CPU virtualization does to targeting your code.
> 
> That's a good point The processor should be specified in the VM 
profile and if I recall correctly it is typically defaulted to the 
processor of the VM host. I should look closer at this -- but would like 
some feedback.
> 
> Thanks,
> 
> _M
> 
> -- 
> Pete McNeil
> Chief Scientist
> ARM Research Labs, LLC
> www.armresearch.com
> 866-770-1044 x7010
> twitter/codedweller
> 
> 
> #
> This message is sent to you because you are subscribed to
> the mailing list .
> This list is for discussing Message Sniffer,
> Anti-spam, Anti-Malware, and related email topics.
> For More information see http://www.armresearch.com
> To unsubscribe, E-mail to: 
> To switch to the DIGEST mode, E-mail to 
> To switch to the INDEX mode, E-mail to 
> Send administrative queries to  
> 

[sniffer] Re: What is your oldest production CPU?

[eric]

Current here.





Sent using SmarterSync Over-The-Air sync for iPad, iPhone, BlackBerry and 
other SmartPhones.  May use speech to text.  If something seems odd please 
don't hesitate to ask for clarification.  E.&O.E.

> On Dec 27, 2013, at 6:46 AM, Pete McNeil  
wrote:
> 
> Hello Sniffer Folks,
> 
> We would like to know what your oldest production CPU is.
> 
> When building new binaries of SNF or it's utilities we would like to 
select the newest CPU we can without leaving anybody behind.
> 
> We're also evaluating whether we should split binaries into a 
"compatible" version base on Intel i686 (or equivalent AMD), and a 
"current" version based on Intel Core2 (or equivalent AMD).
> 
> Please respond here.
> 
> Thanks for your time!!
> 
> _M
> 
> -- 
> Pete McNeil
> Chief Scientist
> ARM Research Labs, LLC
> www.armresearch.com
> 866-770-1044 x7010
> twitter/codedweller
> 
> 
> #
> This message is sent to you because you are subscribed to
> the mailing list .
> This list is for discussing Message Sniffer,
> Anti-spam, Anti-Malware, and related email topics.
> For More information see http://www.armresearch.com
> To unsubscribe, E-mail to: 
> To switch to the DIGEST mode, E-mail to 
> To switch to the INDEX mode, E-mail to 
> Send administrative queries to  
> 

[sniffer] Re: Slow processing times, errors

[E. H. (Eric) Fletcher]

I should add that Sniffer has been pretty much trouble free for us.  We have
been using it since before the ARM research days (10+ years as a guess).
One of the specialized clients we host for goes through a cycle every few
years where they are very publically visible and there are a number of
attempts to infect them and do other things to take mail and other services
down as well as huge volumes of SPAM directed a couple of hundred additional
published and very visible email addresses.  For several weeks the mail
volume and bandwidth utilization go up dramatically (10X).  Sniffer is
in-line with other processes and has handled the load without a wrinkle.
Whatever we've seen just recently, and as I reflect on it possibly once
before, is definitely out of the ordinary for us.

 

 

From: Message Sniffer Community [mailto:sniffer@sortmonster.com] On Behalf
Of Matt
Sent: Friday, June 28, 2013 11:31 AM
To: Message Sniffer Community
Subject: [sniffer] Re: Slow processing times, errors

 

I'll certainly look more closely next time.  Hopefully I'll be migrated
before this happens again :)

Matt



On 6/28/2013 1:44 PM, Darin Cox wrote:

How about running performance monitor to watch disk I/O, mem, cpu, page
file, etc. over time in the hopes of catching one of the events?

 

Darin.

 

From: Matt   

Sent: Friday, June 28, 2013 12:10 PM

To: Message Sniffer Community   

Subject: [sniffer] Re: Slow processing times, errors

 

Pete,

I'm near positive that it's not system resources that are causing Sniffer to
not be able to access the files.  I believe these errors are a symptom and
not the cause.

You have to keep in mind that on the messages that don't throw errors, they
were taking 30-90 seconds to scan, but immediately after a restart it was
under 1 second.  The system stayed the same, it was just the state of the
service that was off in a bad way.

I did add a larger client about a month ago around the time that this
started, which did inch up load by between 1% and 5% I figure, but I can't
say for sure that the two things are connected.  I've seen much bigger
changes however in spam volumes from single spammers.  I have looked at my
SNFclient.exe.err log and found that the previous slowdowns were all
represented in this file, and nothing else really since a smattering in 2012
of other stuff.  I believe that I/O could be the trigger, or general system
load, but the error in the service that misses opening some files, and is
otherwise slower than normal by 100 times, will persist when everything else
is fine again.  I figure that this is all triggered by a short-term lack of
resources or a killer message type of issue that does something like run
away with memory.  Certainly there were no recent changes on the server
prior to this starting to happen, including Sniffer itself which has been
perfectly solid up until 5/22.

Regarding the ERROR_MSG_FILE batch that I sent you in that log, it did
happen exactly when I restarted Sniffer, and in fact the SNFclient.exe.err
log showed a different error while this was happening, and maybe this will
point you to something else?  That log says "Could Not Connect!" when the
regular Sniffer log shows "ERROR_MSG_FILE" about 1/8th of the time while in
a bad state.  When I restarted the Sniffer service, the regular log showed a
bunch of "ERROR_MSG_FILE" in a row, but the SNFclient.exe.err log below
shows "XCI Error!: FileError snf_EngineHandler::scanMessageFile()
Open/Seek".  You can match the message ID's with the other log that I
provided.  I believe that block of messages was already called to
SNFclient.exe, but the Sniffer service haddn't yet responded, and so they
were dumped as a batch into both logs during shut down of the service.

20130627183807, arg1=F:\\proc\work\D862600e64269.smd : Could Not
Connect!
20130627183808, arg1=F:\\proc\work\D86440177431f.smd : Could Not
Connect!
20130627183808, arg1=F:\\proc\work\D861200ce41ce.smd : Could Not
Connect!
20130627183809, arg1=F:\\proc\work\D864401734321.smd : Could Not
Connect!
20130627183809, arg1=F:\\proc\work\D861400da41e3.smd : Could Not
Connect!
20130627183810, arg1=F:\\proc\work\D862600d7425f.smd : Could Not
Connect!
20130627183811, arg1=F:\\proc\work\D864a00e94346.smd : Could Not
Connect!
20130627183811, arg1=F:\\proc\work\D8615019b41f4.smd : Could Not
Connect!
20130627183813, arg1=F:\\proc\work\D862900e94282.smd : Could Not
Connect!
20130627183815, arg1=F:\\proc\work\D863d01584306.smd : Could Not
Connect!
20130627183817, arg1=F:\\proc\work\D86030158416f.smd : Could Not
Connect!
20130627183818, arg1=F:\\proc\work\D862300e94255.smd : Could Not
Connect!
20130627183819, arg1=F:\\proc\work\D862900e64281.smd : Could Not
Connect!
20130627183819, arg1=F:\\proc\work\D864b00d74357.smd : XCI Error!:
FileError snf_EngineHandler::scanMessageFile() Open/Seek
20130627183819, arg1=F:\\proc\work\D864800d7433c.smd 

[sniffer] Re: Slow processing times, errors

[eric]

Matt:
Coincidentally (I hope) this happened to us on the 22nd also.  It did not 
stop working completely although we didn't get the throughput you did.  We 
also saw the messages indicating it was not able to open the file. Pretty 
much the same message as in your first post and not one I've seen before.
Eric




Sent using SmarterSync Over-The-Air sync for iPad, iPhone, BlackBerry and 
other SmartPhones.  May use speech to text.  If something seems odd please 
don't hesitate to ask for clarification.  E.&O.E.

On 2013-06-28, at 11:39 AM, Matt  wrote:

> Eric,
> 
> I'm guessing based on what you were seeing, that it was unrelated to what 
I was seeing.  Sniffer never actually died, it just got over 100 times 
slower, and 1/8th of the time it timed out.  This never happened before 
5/22, and this same server has been there for years, and the same 
installation of Sniffer for 2 years or so.  I would think that if the issue 
was I/O (under normal conditions), it would have happened before 5/22 as 
there were clearly bursty periods often enough that my own traffic didn't 
change dramatically enough so that it happened 4 to 5 times in one month.
> 
> The server itself could have some issues that could be causing this.  
Maybe the file system is screwy, or Windows itself, or memory errors, or 
whatever.
> 
> Matt
> 
> 
> On 6/28/2013 2:12 PM, E. H. (Eric) Fletcher wrote:
>> Matt:
>> 
>> I mentioned in a previous post that we had experienced something similar 
at
>> about that time and resolved it a day or so later by re-installing 
sniffer
>> when service restarts, reboots and some basic troubleshooting did not 
give
>> us the results we needed.  At this point that still seems to have been
>> effective (about 5 days now).
>> 
>> At the time, we did move things around to see whether it was related to 
the
>> number of items in the queue or anywhere else within the structure of 
the
>> mail system and found it made no difference. A single item arriving in 
an
>> empty Queue was still not processed.   CPU utilization was modest 
(single
>> digit across 4 cores) and disk I/O was lighter than usual as it took 
place
>> over a weekend.  Memory utilization was a little higher than I'd like 
to
>> see, we are addressing that now.
>> 
>> Following a suggestion from another ISP, we moved the spool folders onto 
a
>> RAM drive a couple of months ago.  That has worked well for us, we did 
rule
>> it out as the source of the problem by moving back onto the 
conventional
>> hard disk during the last part of the troubleshooting and for the first 
hour
>> or two following the reload.  We are processing on the Ramdisk now and 
have
>> been for over 4 days again.
>> 
>> For what it's worth . . .
>> 
>> Eric
>> 
>> 
>> -Original Message-
>> From: Message Sniffer Community [mailto:sniffer@sortmonster.com] On 
Behalf
>> Of Matt
>> Sent: Friday, June 28, 2013 10:32 AM
>> To: Message Sniffer Community
>> Subject: [sniffer] Re: Slow processing times, errors
>> 
>> Pete,
>> 
>> Just after the restart of the Sniffer service, times dropped back down 
into
>> the ms from 30+ seconds before, so what I am saying is that if I/O was 
the
>> issue, it was merely the trigger for something that put the service in a 
bad
>> state when it started.  I/O issues are not persistent, but could happen 
from
>> time to time I'm sure. Restarting Sniffer with a backlog of 2,500 
messages
>> and normal peak traffic will not re-trigger the condition, and I press
>> Declude to run up to 300 messages at a time in situations like that, and 
the
>> CPU's are pegged until the backlog clears.  In the past, I restarted 
the
>> whole system, not knowing why it worked.  During normal peak times 
(without
>> bursts), the Declude is processing about 125 messages at a time which 
take
>> an average of 6 seconds to fully process, and therefore Sniffer is 
probably
>> handling only about 10 messages at a time (at peak).
>> 
>> Since 5/22 I have seen 4 or 5 different events like this, and I 
confirmed
>> that they are all present in the SNFclient.exe.err log.
>> 
>> Matt
>> 
>> 
>> 
>> On 6/28/2013 12:41 PM, Pete McNeil wrote:
>>> On 2013-06-28 12:10, Matt wrote:
>>>> I am looking to retool presently just because it's time.  So if you
>>>> are convinced that this is due to low resources, don't concern
>>>> yourself with it.
>>> Ok. It makes sense that the ~200 messages all at once could have
>>> happend at the restart. SNFClient will keep trying for 30-90 seconds
>>

[sniffer] Re: Slow processing times, errors

[E. H. (Eric) Fletcher]

Matt:

I mentioned in a previous post that we had experienced something similar at
about that time and resolved it a day or so later by re-installing sniffer
when service restarts, reboots and some basic troubleshooting did not give
us the results we needed.  At this point that still seems to have been
effective (about 5 days now).

At the time, we did move things around to see whether it was related to the
number of items in the queue or anywhere else within the structure of the
mail system and found it made no difference. A single item arriving in an
empty Queue was still not processed.   CPU utilization was modest (single
digit across 4 cores) and disk I/O was lighter than usual as it took place
over a weekend.  Memory utilization was a little higher than I'd like to
see, we are addressing that now.

Following a suggestion from another ISP, we moved the spool folders onto a
RAM drive a couple of months ago.  That has worked well for us, we did rule
it out as the source of the problem by moving back onto the conventional
hard disk during the last part of the troubleshooting and for the first hour
or two following the reload.  We are processing on the Ramdisk now and have
been for over 4 days again.

For what it's worth . . .

Eric


-Original Message-
From: Message Sniffer Community [mailto:sniffer@sortmonster.com] On Behalf
Of Matt
Sent: Friday, June 28, 2013 10:32 AM
To: Message Sniffer Community
Subject: [sniffer] Re: Slow processing times, errors

Pete,

Just after the restart of the Sniffer service, times dropped back down into
the ms from 30+ seconds before, so what I am saying is that if I/O was the
issue, it was merely the trigger for something that put the service in a bad
state when it started.  I/O issues are not persistent, but could happen from
time to time I'm sure. Restarting Sniffer with a backlog of 2,500 messages
and normal peak traffic will not re-trigger the condition, and I press
Declude to run up to 300 messages at a time in situations like that, and the
CPU's are pegged until the backlog clears.  In the past, I restarted the
whole system, not knowing why it worked.  During normal peak times (without
bursts), the Declude is processing about 125 messages at a time which take
an average of 6 seconds to fully process, and therefore Sniffer is probably
handling only about 10 messages at a time (at peak).

Since 5/22 I have seen 4 or 5 different events like this, and I confirmed
that they are all present in the SNFclient.exe.err log.

Matt



On 6/28/2013 12:41 PM, Pete McNeil wrote:
> On 2013-06-28 12:10, Matt wrote:
>> I am looking to retool presently just because it's time.  So if you 
>> are convinced that this is due to low resources, don't concern 
>> yourself with it.
>
> Ok. It makes sense that the ~200 messages all at once could have 
> happend at the restart. SNFClient will keep trying for 30-90 seconds 
> before it gives up and spits out it's error file. That's where your 
> delays are coming from. SNF itself was clocking only about 100-800ms 
> for all of the scans.
>
> The error result you report is exactly the one sent by SNF -- that it 
> was unable to open the file.
>
> I am very sure this is resource related -- your scans should not be 
> taking the amount of time they are and I suspect most of that time is 
> eaten up trying to get to the files. The occasional errors of the same 
> time are a good hint that IO is to blame.
>
> The new spam that we've seen often includes large messages -- so 
> that's going to put a higher load on IO resources -- I'll bet that the 
> increased volume and large message sizes are pushing IO over the edge 
> or at least very close to it.
>
> Best,
>
> _M
>



#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer, Anti-spam, Anti-Malware, and
related email topics.
For More information see http://www.armresearch.com To unsubscribe, E-mail
to:  To switch to the DIGEST mode, E-mail to
 To switch to the INDEX mode, E-mail to
 Send administrative queries to




#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer,
Anti-spam, Anti-Malware, and related email topics.
For More information see http://www.armresearch.com
To unsubscribe, E-mail to: 
To switch to the DIGEST mode, E-mail to 
To switch to the INDEX mode, E-mail to 
Send administrative queries to  

[sniffer] Re: Slow processing times, errors

[eric]

We were experiencing this several days ago and couldn't find a fix that 
worked or worked for long.  We uninstalled SNF and reinstalled and have not 
detected a problem since.  I will check the logs and report back if I see 
anything intermittent.




Sent using SmarterSync Over-The-Air sync for iPad, iPhone, BlackBerry and 
other SmartPhones.  May use speech to text.  If something seems odd please 
don't hesitate to ask for clarification.  E.&O.E.

On 2013-06-27, at 2:06 PM, Matt  wrote:

> Pete,
> 
> I've had many recent incidences where, as it turns out, SNFclient.exe 
takes 30 to 90 seconds to respond to every message with a result code 
(normally less than a second), and as a result backs up processing.  
Restarting the Sniffer service seems to do the trick, but I only tested 
that for the first time today after figuring this out.
> 
> I believe the events are triggered by updates, but I'm not sure as of 
yet.  Updates subsequent to the slow down do not appear to fix the 
situation, so it seems to be resident in the service.  When this happens, 
my SNFclient.exe.err log fill up with lines like this:
> 
>20130627155608, arg1=F:\\proc\work\D6063018a2550.smd : Could Not 
Connect!
> 
> At the same time, my Sniffer logs start showing frequent "ERROR_MSG_FILE" 
results on about 1/8th of the messages.
> 
> I'm currently using the service version 3.0.2-E3.0.17.  It's not entirely 
clear to me what the most current one is.
> 
> Any suggestions as to the cause or solution?
> 
> Thanks,
> 
> Matt
> 
> 
> #
> This message is sent to you because you are subscribed to
> the mailing list .
> This list is for discussing Message Sniffer,
> Anti-spam, Anti-Malware, and related email topics.
> For More information see http://www.armresearch.com
> To unsubscribe, E-mail to: 
> To switch to the DIGEST mode, E-mail to 
> To switch to the INDEX mode, E-mail to 
> Send administrative queries to  
> 

[sniffer] Re: 2nd level IP scanning

[eric]

This might also be effective where the spammer hits the high MX entry acting as 
a gateway.
MxGuard could be configured to use the GBUDB I think and to look up to 5 levels 
deep.




Sent using SmarterSync Over-The-Air sync for iPad, iPhone, BlackBerry and other 
SmartPhones.  May use speech to text.  If something seems odd please don't 
hesitate to ask for clarification.  E.&O.E.

On 2013-06-07, at 3:17 PM, "Peer-to-Peer \(Spam-Filter.com\)" 
 wrote:

> Hey Pete and all,
>
> Is there an option to have SNF scan second or third deep header IP's?   I'm 
> trying to block an originating IP (66.83.88.42), however they are hopping 
> thru Comcast and Verizon.
>
>
> Thanks,
>
> --Paul

[sniffer] Re: Convert your Declude OEM license now and get full credit!

[E. H. (Eric) Fletcher]

David Gregg's mxGuard product has been rock solid for us for years but a
full integration into SmarterMail would be nice.

-Original Message-
From: Message Sniffer Community [mailto:sniffer@sortmonster.com] On Behalf
Of John Moore
Sent: Thursday, April 11, 2013 5:32 AM
To: Message Sniffer Community
Subject: [sniffer] Re: Convert your Declude OEM license now and get full
credit!

YES!

-Original Message-
From: Message Sniffer Community [mailto:sniffer@sortmonster.com] On Behalf
Of e...@insight.rr.com
Sent: Thursday, April 11, 2013 7:23 AM
To: Message Sniffer Community
Subject: [sniffer] Re: Convert your Declude OEM license now and get full
credit!

Because of this entire issue with declude. It might be nice if you contacted
smarterTools and offered to work with them on them integrating message
sniffer directly into smarterMail. :)



-Original Message-
From: Message Sniffer Community [mailto:sniffer@sortmonster.com] On Behalf
Of Pete McNeil
Sent: Wednesday, April 10, 2013 3:04 PM
To: Message Sniffer Community
Subject: [sniffer] Convert your Declude OEM license now and get full credit!

Hi Sniffer Folks,

It appears that Declude (the company) is failing. After many rumors of
problems and some first hand experience, today the Declude web site has gone
dark.

We have a long standing relationship with the Declude community, and we want
to make sure we do what we can to support them even if Declude itself goes
away.

Place a new order for Message Sniffer (SNF) now and we will give you credit
for any time you have left on your Declude OEM license. Tell us your OEM
expiration date with Declude and we will add the time you have left to your
new SNF license.

For the best pricing we recommend you purchase through one of our resellers:
https://www.armresearch.com/products/resellers.jsp

Please be sure to pass this information on to any interested folks that
might not be on this list! There is bound to be a lot of turmoil right now
and we don't want anybody to miss it.

Please let us know if there is more we can do!

Best,

_M

--
Pete McNeil
Chief Scientist
ARM Research Labs, LLC
www.armresearch.com
866-770-1044 x7010
twitter/codedweller


#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer, Anti-spam, Anti-Malware, and
related email topics.
For More information see http://www.armresearch.com To unsubscribe, E-mail
to:  To switch to the DIGEST mode, E-mail to
 To switch to the INDEX mode, E-mail to
 Send administrative queries to





#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer, Anti-spam, Anti-Malware, and
related email topics.
For More information see http://www.armresearch.com To unsubscribe, E-mail
to:  To switch to the DIGEST mode, E-mail to
 To switch to the INDEX mode, E-mail to
 Send administrative queries to




#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer, Anti-spam, Anti-Malware, and
related email topics.
For More information see http://www.armresearch.com To unsubscribe, E-mail
to:  To switch to the DIGEST mode, E-mail to
 To switch to the INDEX mode, E-mail to
 Send administrative queries to





#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer,
Anti-spam, Anti-Malware, and related email topics.
For More information see http://www.armresearch.com
To unsubscribe, E-mail to: 
To switch to the DIGEST mode, E-mail to 
To switch to the INDEX mode, E-mail to 
Send administrative queries to  

[sniffer] Re: Direct SmarterMail integration -- Some Testers ?

[E. H. (Eric) Fletcher]

I'd definitely favor B.  Sniffer is so good at what it does that there is
some real potential there depending on the degree to which you integrate
with the SM anti-spam features like SMTP blocking for example.  This would
take some real work of course.

-Original Message-
From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf
Of Pete McNeil
Sent: Wednesday, June 09, 2010 6:46 PM
To: Message Sniffer Community
Subject: [sniffer] Re: Direct SmarterMail integration -- Some Testers ?

On 6/9/2010 6:54 PM, E. H. (Eric) Fletcher wrote:
> I wonder whether it doesn't become a solution in search of a problem.
>

We're asked about it frequently, and since the command line option 
already exists it's worth fleshing out a bit.

We've avoided building an interface for the proc hooks because:

A. There are already solutions there for that (as you point out).

B. We would really like to see a much tighter integration with SM that 
can take full advantage (during SMTP, not after).

If enough folks are interested in a proc hook based implementation of 
SNF then we will do it, of course.

_M


-- 
Chief Scientist
ARM Research Labs, LLC
www.armresearch.com


#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer,
Anti-spam, Anti-Malware, and related email topics.
For More information see http://www.armresearch.com
To unsubscribe, E-mail to: 
To switch to the DIGEST mode, E-mail to 
To switch to the INDEX mode, E-mail to 
Send administrative queries to  




#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer,
Anti-spam, Anti-Malware, and related email topics.
For More information see http://www.armresearch.com
To unsubscribe, E-mail to: 
To switch to the DIGEST mode, E-mail to 
To switch to the INDEX mode, E-mail to 
Send administrative queries to  

[sniffer] Re: Direct SmarterMail integration -- Some Testers ?

[E. H. (Eric) Fletcher]

Great, I missed that, thanks!

-Original Message-
From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf
Of e...@insight.rr.com
Sent: Wednesday, June 09, 2010 4:08 PM
To: Message Sniffer Community
Subject: [sniffer] Re: Direct SmarterMail integration -- Some Testers ?

SmarterMail - doesn't use an external SpamAssassin any longer.
It will now scan emails internally using the SpamAssassin update files or
whatever they are called.
SmarterTools said they had too many issues with trying to use the windows
version and just decided
To do some internal integration.




#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer,
Anti-spam, Anti-Malware, and related email topics.
For More information see http://www.armresearch.com
To unsubscribe, E-mail to: 
To switch to the DIGEST mode, E-mail to 
To switch to the INDEX mode, E-mail to 
Send administrative queries to  




#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer,
Anti-spam, Anti-Malware, and related email topics.
For More information see http://www.armresearch.com
To unsubscribe, E-mail to: 
To switch to the DIGEST mode, E-mail to 
To switch to the INDEX mode, E-mail to 
Send administrative queries to  

[sniffer] Re: Direct SmarterMail integration -- Some Testers ?

[E. H. (Eric) Fletcher]

I wonder whether it doesn't become a solution in search of a problem.  David
Gregg over at mxGuard is small to be sure and on the licensing plan he's
used in recent years I suppose mxGuard might quite working if he ceased
doing business; however, his product is very reasonably priced, very light
weight in terms of CPU load and from everything we've seen over 7 years or
so, absolutely reliable.  When I looked into converting one of our servers
over to SmarterMail there seemed to be some thinking that the SpamAssassin
that would install automatically might create problems at what seemed to be
modest traffic levels so we chose not to enable it.  Running a separate
SpamAssassin server would be simple enough but if what we gain from it is
simply the ability to use Sniffer I'm not sure it's superior to the mxGuard
approach.

I haven't looked at what would be involved (and have actually found a few
things I like about inserting Sniffer in ahead of the rest of the processes)
but being able to fully integrate Sniffer into the SmarterMail GUI and
reporting might be more interesting than simply finding a free way of
shoehorning it in.  I say this until I wake up and find mxGuard out of
business of course.  I think it would be almost trivial to write something
to replace mxGuard's ability to integrate Sniffer using the SmarterMail PROC
hooks if something did go wrong but have appreciated the work David has done
even if we don't use any of the other hooks any more so haven't had any
interest in competing and at $100 my time is worth more to me in terms of
doing it just for our own use.

I understand it's probably a good move for ARM though as long as most
SmarterMail sites do use SpamAssassin.



-Original Message-
From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf
Of Pete McNeil
Sent: Wednesday, June 09, 2010 3:29 PM
To: Message Sniffer Community
Subject: [sniffer] Re: Direct SmarterMail integration -- Some Testers ?

On 6/9/2010 6:15 PM, David Moore wrote:
> We use MX Guard / Invuribl / Sniffer combo would it be a matter of 
> removing Sniffer from the MXGuard.ini ? I would still like to use all 
> 3 options.

Theoretically that should work... so that you don't call SNF twice.

What SNF is going to do in the SM command line is simply add headers to 
the message.
Then, you can add some rules to SMs SpamAssassin to convert those 
headers to weights.

_M

-- 
Chief Scientist
ARM Research Labs, LLC
www.armresearch.com


#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer,
Anti-spam, Anti-Malware, and related email topics.
For More information see http://www.armresearch.com
To unsubscribe, E-mail to: 
To switch to the DIGEST mode, E-mail to 
To switch to the INDEX mode, E-mail to 
Send administrative queries to  




#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer,
Anti-spam, Anti-Malware, and related email topics.
For More information see http://www.armresearch.com
To unsubscribe, E-mail to: 
To switch to the DIGEST mode, E-mail to 
To switch to the INDEX mode, E-mail to 
Send administrative queries to  

[sniffer] Re: Direct SmarterMail integration -- Some Testers ?

[E. H. (Eric) Fletcher]

I'd be willing to take a shot at it in the dead of the night (when spam
ratio is high) and if we get through that in production during the day.  Is
there any failsafe in place to remove it from the loop if it detects it is
not performing as expected?


-Original Message-
From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf
Of Pete McNeil
Sent: Wednesday, June 09, 2010 12:02 PM
To: Message Sniffer Community
Subject: [sniffer] Re: Direct SmarterMail integration -- Some Testers ?

On 6/9/2010 2:44 PM, Pete McNeil wrote:
> Hello Sniffer Folks,
>
> We are working on testing and improving direct integration options 
> with Smarter Mail.

Shamelessly responding to my own post, I thought I would point out:

You do not need to re-install Message Sniffer to test this option. If 
you already have Message Sniffer installed then you can access it with 
SNFClient already.

There is no need to disturb what you've already got running except 
perhaps to adjust how you are responding to what SNF finds.

Best,

_M

-- 
Chief Scientist
ARM Research Labs, LLC
www.armresearch.com


#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer,
Anti-spam, Anti-Malware, and related email topics.
For More information see http://www.armresearch.com
To unsubscribe, E-mail to: 
To switch to the DIGEST mode, E-mail to 
To switch to the INDEX mode, E-mail to 
Send administrative queries to  




#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer,
Anti-spam, Anti-Malware, and related email topics.
For More information see http://www.armresearch.com
To unsubscribe, E-mail to: 
To switch to the DIGEST mode, E-mail to 
To switch to the INDEX mode, E-mail to 
Send administrative queries to  

[sniffer] Re: Changing result code for truncate.gbudb.net to 127.0.0.2

[E. H. (Eric) Fletcher]

Perfect, thanks!

-Original Message-
From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf
Of Pete McNeil
Sent: Friday, April 30, 2010 10:51 AM
To: Message Sniffer Community
Subject: [sniffer] Changing result code for truncate.gbudb.net to 127.0.0.2

Hello Sniffer Folks,

RFC 5782 states:

"IPv4-based DNSxLs MUST NOT contain an entry for 127.0.0.1."

and also states:

"The A record contents conventionally have the  value 127.0.0.2"

So we will be changing the result code for truncate.gbudb.net to 
127.0.0.2 effective immediately.

Thanks!

_M

-- 
Chief Scientist
ARM Research Labs, LLC
www.armresearch.com


#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer,
Anti-spam, Anti-Malware, and related email topics.
For More information see http://www.armresearch.com
To unsubscribe, E-mail to: 
To switch to the DIGEST mode, E-mail to 
To switch to the INDEX mode, E-mail to 
Send administrative queries to  




#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer,
Anti-spam, Anti-Malware, and related email topics.
For More information see http://www.armresearch.com
To unsubscribe, E-mail to: 
To switch to the DIGEST mode, E-mail to 
To switch to the INDEX mode, E-mail to 
Send administrative queries to  

[sniffer] Re: New proactive false positive preventioninitiatives

[E. H. (Eric) Fletcher]

Steve:
MxGuard is availabe for SmarterMail now. 
Eric

--Original Message--
From: Pete McNeil
Sender: Message Sniffer Community
To: Message Sniffer Community
ReplyTo: Message Sniffer Community
Subject: [sniffer] Re: New proactive false positive preventioninitiatives
Sent: Feb 4, 2010 14:25

Steve Guluk wrote:
> Hey Pete, 
> Is there a hook to use Sniffer in SmarterMail 6?

I haven't looked closely at SM6,... there may be something new.

However, eWall will still work.
Also MXGuard and Declude (Declude just integrated SNF directly).
Also it is possible to run SNF as a command line scanner in SM, though 
most are not happy with that solution.

If their SpamAssassin support has improved you _might_ be able to use 
SNF4SA -- last I heard it was not possible to add plugins, that may have 
changed.

If you have a resolver setup for your mail system (you should) then you 
might also try our truncate bl to block connections -- let me know if 
you're interested in trying that.

If there are newer better ways to integrate I'd love to know about them.

Best,

_M


#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer,
Anti-spam, Anti-Malware, and related email topics.
For More information see http://www.armresearch.com
To unsubscribe, E-mail to: 
To switch to the DIGEST mode, E-mail to 
To switch to the INDEX mode, E-mail to 
Send administrative queries to  



Sent from my BlackBerry® using speech recognition so may be brief and may 
contain errors.  Please don't hesitate to ask for confirmation if anything 
seems incomplete or innacurate.  E&OE.  
#
This message is sent to you because you are subscribed to
  the mailing list .
This list is for discussing Message Sniffer,
Anti-spam, Anti-Malware, and related email topics.
For More information see http://www.armresearch.com
To unsubscribe, E-mail to: 
To switch to the DIGEST mode, E-mail to 
To switch to the INDEX mode, E-mail to 
Send administrative queries to  

[sniffer] Re: Upgraded Rulebase Delivery System - All OK here

[E. H. (Eric) Fletcher]

Pete:

We have a regional based trap running post-Sniffer.  When Sniffer hiccups 
(or we've done something to cause it to hiccup) there are thousands of mails 
in it over the space of a few hours, almost all spam.


There is no increase there overnight so our rulebases are definitely still 
working as expected.


On that note, we ended up having to go to the RC code very early this year 
because of the increasing high levels of spam getting through the last 
release version.  I know this shouldn't have been the case but in that final 
RC version we were running the leakage was fairly significant, 
(approximately 40 times what it was in a typical night like last night for 
example).  The rule base updates were working and all mail was getting 
vetted but some part of the magic you do didn't seem to be working.  We 
waited a week or so following your release notice for 3.0 to install it and 
found an immediate reduction in spam to the sort of levels you were 
achieving for us a year or so ago (adjusted a little for the increased level 
of what's out there today vs. a year ago).


All appears to be well here.

No reply necessary.

Thanks for a great product.
- Original Message - 
From: "Pete McNeil" <[EMAIL PROTECTED]>

To: "Message Sniffer Community" 
Sent: Saturday, July 12, 2008 1:33 AM
Subject: [sniffer] Upgraded Rulebase Delivery System


Hello Sniffer Folks,

Early this morning we completed significant upgrades to our rulebase
delivery system yielding a 10 fold increase in available bandwidth and
a 5 fold increase in delivery transaction rates.

Please let us know if you observe any negative or positive effects.


From observations and theory rulebases should be delivered more

quickly and more frequently.

I will continue to monitor the system closely for any aberrations.

Thanks,

_M

--
Pete McNeil
Chief Scientist,
Arm Research Labs, LLC.


#
This message is sent to you because you are subscribed to
 the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>




#
This message is sent to you because you are subscribed to
 the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>

[sniffer] Re: Backscatter Spam

[E. H. (Eric) Fletcher]

Matt:

We also found SPF records did the trick on the high volume returns to several 
domains especially from some of the appliances.  

Eric
  - Original Message - 
  From: Mxuptime.com 
  To: Message Sniffer Community 
  Sent: Saturday, June 28, 2008 8:50 PM
  Subject: [sniffer] Re: Backscatter Spam


  Intersting idea but the BATV appears to be something that you would need to 
run on the MTA level (i.e the MailServer would need to support the 
functionality) because it rewrites the return address on outgoing emails.

   

  On a side note, I have noticed a significant drop in backscatter when SPF is 
implemented for the particular domain. Most of the backscatter appears to come 
from valid antispam appliances like the Barracuda boxes which would normally 
use SPF. These devices perform the SPF test during the SMTP connection and 
rejects it immediately as opposed to bouncing the message back. So the SPF does 
help.

   

  -Matt

   

  From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of 
Matthew J. Grim
  Sent: Sunday, June 29, 2008 1:25 AM
  To: Message Sniffer Community
  Subject: [sniffer] Re: Backscatter Spam

   

  As an aside, Mdaemon has an excellent backscatter prevention system.

  They appear to be using BATV, an internet draft at the moment.

  Matt in Tampa

[sniffer] Re: Excessive amounts of spam

[E. H. (Eric) Fletcher]

Frank:

Thanks for your input.  There are definitely things leaking though that 
wouldn't have leaked through before.  We've held off hoping for a production 
release but it may not be practical much longer.  On that note, for anyone 
else in the same position, we tested adding InvURIBL from Invariant Systems. 
It's not a sniffer replacement but definitely caught a lot of what sniffer 
currently lets through for the very valid reasons Pete has covered.  The 
only thing missing seemed to be a white list so that you could white list 
legitimate publications that might contain links to 'offensive' sites.  That 
can probably be tuned out thru weighting however we'd hoped not to be 
re-inventing the wheel for a short term solution.


Eric

- Original Message - 
From: "Pi-Web - Frank Jensen" <[EMAIL PROTECTED]>

To: "Message Sniffer Community" 
Sent: Thursday, December 20, 2007 1:17 PM
Subject: [sniffer] Re: Excessive amounts of spam




We have been running it for - I guess - 2 month now without any trouble.



How stable is the beta version?

 Regards David Moore
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

J.P. MCP, MCSE, MCSE + INTERNET, CNE.
www.adsldirect.com.au <http://www.adsldirect.com.au/> for ADSL and 
Internet www.romtech.com.au <http://www.romtech.com.au/> for PC sales


Office Phone: (+612) 9453 1990
Fax Phone: (+612) 9453 1880
Mobile Phone: +614 18 282 648
Skype Phone: ADSLDIRECT

POSTAL ADDRESS:
PO BOX 190
BELROSE NSW 2085
AUSTRALIA.

-

This email message is only intended for the addressee(s) and contains 
information that may be confidential, legally privileged and/or 
copyright. If you are not the intended recipient please notify the sender 
by reply email and immediately delete this email. Use, disclosure or 
reproduction of this email, or taking any action in reliance on its 
contents by anyone other than the intended recipient(s) is strictly 
prohibited. No representation is made that this email or any attachments 
are free of viruses. Virus scanning is recommended and is the 
responsibility of the recipient.


-

 *From:* Message Sniffer Community [mailto:[EMAIL PROTECTED] *On 
Behalf Of *Pete McNeil

*Sent:* Friday, 21 December 2007 8:10 AM
*To:* Message Sniffer Community
*Subject:* [sniffer] Re: Excessive amounts of spam

 Hello David,

 Thursday, December 20, 2007, 3:25:45 PM, you wrote:








Ø  If you are not yet running the latest beta then that might help quite 
a bit since the GBUdb (IP reputation system) does a good job capturing 
new spam from old bots even before rules are coded.


Please clarify are you saying it would help if we had the beta installed?

 Yes. The new GBUdb engine reduces leakage quite a bit. As more systems 
adopt the new version this will improve even more. Most new spam 
campaigns are started with some large fraction of existing bots. Messages 
from bots that have already been identified will be blocked even before 
new content rules can be generated (if needed). _M


 -- 


Pete McNeil

Chief Scientist,

Arm Research Labs, LLC.

#

 This message is sent to you because you are subscribed to

 the mailing list .

 To unsubscribe, E-mail to: <[EMAIL PROTECTED]>

 To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>

 To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>

 Send administrative queries to  <[EMAIL PROTECTED]>





--
Mvh. Frank Jensen
[EMAIL PROTECTED]
www.pi.dk



Imponerende, fascinerende og kæmpe
Plakater f.eks. 149 x 149 = 629 kr
Vi kan også lave plakat fra dit digitale foto

www.plakatkunst.dk



#
This message is sent to you because you are subscribed to
 the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>






#
This message is sent to you because you are subscribed to
 the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>

[sniffer] Re: After Updating MXGUARD

[E. H. (Eric) Fletcher]

Alberto:

I haven't finished looking but one note I did make was that the syntax in 
MxGuard.INI had changed slightly to include a comma.


[GLOBAL]
Our working file under v1.7: SpamFilterType=NATIVE SNIFFER
Our working file under v3.1: SpamFilterType=NATIVE, SNIFFER

I will continue to look at this for you.

Eric

- Original Message - 
From: "Alberto Santoni" <[EMAIL PROTECTED]>

To: "Message Sniffer Community" 
Sent: Thursday, June 28, 2007 11:42 AM
Subject: [sniffer] Re: After Updating MXGUARD


Pete,

after a day the SNF doesn't work yet ... what else can I try?
I have checked all that possible

With my best regards
Alberto Santoni
---
ASPita Sprl
Grande rue au Bois, 196 - 1030 - Brussels
+32(0)2 217 85 28 office
+32(0)2 735 78 65 fax
+32(0)476 53 88 34 mobile
Skype: Aspita.be
---



-Original Message-
From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On

Behalf

Of Pete McNeil
Sent: 27 June 2007 23:44
To: Message Sniffer Community
Subject: [sniffer] Re: After Updating MXGUARD

Hello Alberto,

Wednesday, June 27, 2007, 5:15:58 PM, you wrote:

> Hello

> After an update of MxGuard 1.7 -> 3.1 the Sniffer doesn't work any

more

> 
> I have the Sniffer in persistent mode and loaded with Srvany
> I found many files I never seen in the Sniffer dir .SRV .FIN .XXX

> Which tests can I do to understand the problem ?

It turns out that those files have always been there - but most of
them (not the SRV) went away very quickly.

Most likely during your transition your SNF workspace got clogged with
a lot of these and that is causing some problems.

First thing to do is to shut down SMTP & SNF (your persistent
instance) and clear out all of those job files. Each file represents a
sing scan job - the extension represents the status. With everything
shut down there should be none of these files so it's safe to delete
them.

Once that is done you can start things up again and everything should
work normally.

If not then the normal testing procedures should help you discover the
problem quickly.

Hope this helps,

_M


--
Pete McNeil
Chief Scientist,
Arm Research Labs, LLC.


#
This message is sent to you because you are subscribed to
  the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to

<[EMAIL PROTECTED]>

To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>




#
This message is sent to you because you are subscribed to
 the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>




#
This message is sent to you because you are subscribed to
 the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>

[sniffer] Re: After Updating MXGUARD

[E. H. (Eric) Fletcher]

Albert:

I remember there was some small trick to this when I did it a year or so 
ago.  If I remember right there was a change to the MxGuard INI file that 
wasn't obvious.  I'll take a look in a bit and see if I can get back to you 
with something.


Eric

- Original Message - 
From: "Alberto Santoni" <[EMAIL PROTECTED]>

To: "Message Sniffer Community" 
Sent: Thursday, June 28, 2007 11:42 AM
Subject: [sniffer] Re: After Updating MXGUARD


Pete,

after a day the SNF doesn't work yet ... what else can I try?
I have checked all that possible

With my best regards
Alberto Santoni
---
ASPita Sprl
Grande rue au Bois, 196 - 1030 - Brussels
+32(0)2 217 85 28 office
+32(0)2 735 78 65 fax
+32(0)476 53 88 34 mobile
Skype: Aspita.be
---



-Original Message-
From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On

Behalf

Of Pete McNeil
Sent: 27 June 2007 23:44
To: Message Sniffer Community
Subject: [sniffer] Re: After Updating MXGUARD

Hello Alberto,

Wednesday, June 27, 2007, 5:15:58 PM, you wrote:

> Hello

> After an update of MxGuard 1.7 -> 3.1 the Sniffer doesn't work any

more

> 
> I have the Sniffer in persistent mode and loaded with Srvany
> I found many files I never seen in the Sniffer dir .SRV .FIN .XXX

> Which tests can I do to understand the problem ?

It turns out that those files have always been there - but most of
them (not the SRV) went away very quickly.

Most likely during your transition your SNF workspace got clogged with
a lot of these and that is causing some problems.

First thing to do is to shut down SMTP & SNF (your persistent
instance) and clear out all of those job files. Each file represents a
sing scan job - the extension represents the status. With everything
shut down there should be none of these files so it's safe to delete
them.

Once that is done you can start things up again and everything should
work normally.

If not then the normal testing procedures should help you discover the
problem quickly.

Hope this helps,

_M


--
Pete McNeil
Chief Scientist,
Arm Research Labs, LLC.


#
This message is sent to you because you are subscribed to
  the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to

<[EMAIL PROTECTED]>

To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>




#
This message is sent to you because you are subscribed to
 the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>




#
This message is sent to you because you are subscribed to
 the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>

[sniffer] Re: Integration with Mailenable -> Domain Keys

[E. H. (Eric) Fletcher]

Phil / Jay:

I am also looking at SmarterMail as an addition to or replacement for 
several IMail servers and looking at calling MessageSniffer from it without 
Declude because of the Declude bundling of things we don't want or see value 
in.  While doing a little more reading on the SmarterTools site I saw a link 
that addresses your discussion on domain keys:


http://smartermail.exhalus.net/domainkeys/


Eric

- Original Message - 
From: "Jay Sudowski - Handy Networks LLC" <[EMAIL PROTECTED]>

To: "Message Sniffer Community" 
Sent: Saturday, March 17, 2007 1:43 PM
Subject: [sniffer] Re: Integration with Mailenable


Hi Phil -

Good question.  We integrate Sniffer into SmarterMail via Declude.
However, SmarterMail does have the capability to run a program against a
message before it is delivered.  We have some customers that use a batch
file to call f-prot and get virus scanning integrated into their mail
server on the cheap.  I believe it would likely be possible to make use
of the same functionality to call Sniffer directly, and thus avoid
having to purchase Declude.  I have just never had a need to attempt
this.

As for domain keys, I don't believe so.  However, you can setup
SPFyou're your domains simply by adding the appropriate DNS records to
said domains zone files.

-Jay

-Original Message-
From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On
Behalf Of Phillip Cohen
Sent: Friday, March 16, 2007 12:01 PM
To: Message Sniffer Community
Subject: [sniffer] Re: Integration with Mailenable


Jay,

Thanks for the heads up on Mailenable. I took a look at SmarterMail
and it looks pretty good. How does it interface with Message Sniffer
or does it require and external gateway such as EWall? How has
support been with it and how have they been as far as updates. Also
does it have "domain keys" capability and SPF support for sending
mail to yahoo.com etc...

Thanks,

Phil


At 07:26 PM 3/15/2007, you wrote:

Stay Away From MailEnable.

There are so many exploits out there for MailEnable, and there are more
exploits found monthly, if not weekly.  At one particular interval,
MailEnable had to re-release the same patch several times in the *same*
week because it kept on not actually fixing the root of the issue.  If
you run MailEnable, odds are that you will end up exploited, even if

you

stay on the of the patches.

On top of that, MailEnable is just simply a CPU and IO hog, much more

so

than other other mail server I have ever seen.  By default, they use
entirely text based configuration files, which on occasion get

truncated

to zero during periods of high activity on the server.

In the past year, we have assisted our customers move 20,000+ mailboxes
away from MailEnable, mostly all to SmarterMail.  Do not waste your

time

and money with MailEnable.

-Jay

-Original Message-
From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On
Behalf Of Phillip Cohen
Sent: Thursday, March 15, 2007 12:22 PM
To: Message Sniffer Community
Subject: [sniffer] Integration with Mailenable


We are finally going to replace our old Vopmail server. Looking at
Mailenable Enterprise. Will Sortmonster work with that program? Is
anyone using Mailenable? If so how is it and if it works with
Sortmonster how did you use them together.

THanks,

Phil


#
This message is sent to you because you are subscribed to
  the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to

<[EMAIL PROTECTED]>

To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>



#
This message is sent to you because you are subscribed to
  the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to

<[EMAIL PROTECTED]>

To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>



#
This message is sent to you because you are subscribed to
 the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>



#
This message is sent to you because you are subscribed to
 the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>



#
This message is s