Bud Durland wrote:
There's been an almost hysterical reaction to the ICS announcement.
People have right to be angry disappointed over it; but traffic on
he iMail list almost seems like a knee-jerk reaction: Good lord
that's a lot of money -- I'm buying something else right now. If GM
All,
We're missing one huge point and that is why purchase support agreements
from Ipswitch.
Let's review.
1. To get phone support.
2. To get major software updates.
Everyone else keeps adding:
3. To get security hotfixes.
However, #3 is incorrect: From Ipswitch.com
Patches and Upgrades -
The only reason to freak out is because Ipswich has pissed off their
customer base by not giving people a heads up and slapping us in the fact
Well I think a lot of us are concerned because we have invested a lot of
money and time into Imail:
1. platform - Windows vs. free Linux alternative
2.
Great article! Ipswitch wouldnt be the first company destroyed by an MBA,
they seem to be so enamoured with their MBA status that they overlook the
reason the company was succesful in the first place...
I bet the MBAs and Marketing people at Ipswitch ride to and from work in a
short bus
Rick
I don't think any of us would be as upset if a year ago
Ipswitch published their intentions to kill off Imail which
would have allowed everyone to come up with migration plans
or upgrade.
Exactly.
In fact, I find Ipswitch's actions to be completely deceitful.
Here is the email from the 8.12
So, you're saying this is an example of bait and Ipswitch?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark E. Smith
Sent: Wednesday, October 27, 2004 9:48 AM
To: [EMAIL PROTECTED]
Subject: RE: [Declude.JunkMail] Declude and Ipswitch ICS
Exactly.
In
We have been asked to be more explicit as to our future strategy but like
every well managed software company we are reluctant to set expectations we
cannot meet, so with every caveat imaginable in mind here is the outline of
the plan.
Downloadable Windows based version - In design with three
LOL!
Darin.
- Original Message -
From: Sean Fahey [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, October 27, 2004 11:09 AM
Subject: RE: [Declude.JunkMail] Declude and Ipswitch ICS
So, you're saying this is an example of bait and Ipswitch?
-Original Message-
From:
Barry,
Thanks for the insight.
My only suggestion (and this might be the case) is to continue to upgrade
the current product and it's dependency on Imail for at least 12-24 months.
Those of us who are simply using Imail for a Gateway have no real need to
move off of it in the short term.
Thanks!
Funny but sadly true.
Definition: A sales tactic in which a bargain-priced item is used to
attract customers who are then encouraged to purchase a more expensive
similar item.
This is a punishable legal offense. I do think there is very clearly a
basis for action against Ipswitch here. I do
So we have been baited for seven years?? And now the ol' Ipswitch-a-roo??? I
know there is a lot of anger, frustration, etc., but the talk of legal
action is a waste of bandwidth. I'm not happy either, but am not about to
spend 10's of thousands to end up with (as someone said yesterday) a coupon
The seven years enforces the argument, not weakens it. I did not
propose litigation. I stated I think litigation could be successful in
my opinion. Also, WS_FTP has not been discontinued and put into a
suite of products at ten times the costs. So none of these things
apply.
--
Yah, I was cracking a joke but I agree wholeheartedly - it's best to just
move on and get over it. I won't be buying or recommending their products in
the future. Since so many seem to feel the same way, I expect that will hurt
them far more than a lawsuit would. Nothing kills your business faster
Rick,
I was looking at your filter -- great idea.
One question (which falls under the processing order)
If you have:
BODY STOPALLTESTS CONTAINS Content-Type: application/x-zip-compressed
I think Declude Virus will still grab this correct?
Mark
-Original Message-
From: [EMAIL
My wild guess is that the brain trust at Ipswitch decided they either needed to
lower their prices or raise them.
I don't blame them for deciding to switch to a higher pricing / less customers
business plan. I do blame them for what appears to be a horrid transition.
They do have some time to
- Original Message -
From: Mark E. Smith [EMAIL PROTECTED]
Rick,
I was looking at your filter -- great idea.
One question (which falls under the processing order)
If you have:
BODY STOPALLTESTS CONTAINS Content-Type: application/x-zip-compressed
I think Declude Virus will still
One question (which falls under the processing order)
If you have:
BODYSTOPALLTESTS CONTAINS Content-Type: application/x-zip-compressed
I think Declude Virus will still grab this correct?
Declude Virus runs first. So in this case, Declude Virus would scan the
E-mail -- and Declude JunkMail
- Original Message -
From: Barry Simpson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, October 27, 2004 08:23
Subject: [Declude.JunkMail] Declude development strategy
We have been asked to be more explicit as to our future strategy but like
every well managed software
That is correct, declude virus processes before junkmail
I did look at quite a few zip viruses and didnt see any of them using the
Content-Type: application/x-zip-compressed in the mime info
Rick Davidson
National Systems Manager
North American Title Group
-
- Original Message -
From:
Yeah, just checked on a few of these MIME items and the actual type isn't
defined.
For example, an Excel attachment just says application-octet-stream
-0-
Content-Type: multipart/mixed;boundary===IMail_v8.1==
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 27 Oct 2004 18:29:21.0419 (UTC)
Barry,
Thank you very much for sharing this information. Understandably it is
too early to say exactly which one it will be at first, but I think that
both you and your customers benefit from knowing the options considering
the events that transpired. When you commit to a particular platform
That's going to be one massive database :) I've become quite the
VBScripter as of late (if that's something to brag about), so let me
know if you need any help.
Matt
Rick Davidson wrote:
Thanks Matt,
COPYFILE is working perfectly, now its just a matter of writing the
program to parse and
That's a MIME type :) They are all over the place, and they can be
forged. Here's how MS handles it:
http://msdn.microsoft.com/library/default.asp?url="">
Matt
Mark E. Smith wrote:
Yeah, just checked on a few of these MIME items and the actual type isn't
defined.
For example, an Excel
Rick,
I am looking at creating our own email archiving solution using sql
This, as Matt notes, could be monstrous. It certainly is not
best-practice to store this many CLOBs (or BLOBs, if you're decoding
MIME) in a generic DB. That's why the only RDBMS message stores worth
their
Title: Message
Microsoft software is probably the "most guilty" for using the vague
application-octet-stream MIME type instead of something more explicit, like
application/msexcel. PDF is also very likely to come as a stream. I
place viruses and malware asa distant 3rd for using
stream.
As
ok thanks Matt, we do have some programmers on staff here but I will sure
conscript your help if we brick wall. Regardless of where it is stored its
going to be a massive amount of data, my initial samplings show 1.5 to 2GB
per day. Yikes!
You wouldnt happen to know how to parse mime types and
That's funny that you should ask. I just coded that one up in VBScript
this last weekend. I even managed to decode base64 text attachments,
remove quoted-printable encoding, and strip out all of the HTML code.
If this is for archiving according to legal requirement, the attachments
would
Title: Message
Problem was that this wasn't sent through Microsoft OL it
was sent through IMail's web interface.
Also, why would these content types go in the
Body?
Wouldn't they go in the HEADER?
-0-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Colbeck,
Thanks Sandy,
I will look into those, the boss wants me to do this on the cheap, the sql
idea was first so we could at least say we were archiving the email.
Rick Davidson
National Systems Manager
North American Title Group
-
- Original Message -
From: Sanford Whiteman [EMAIL PROTECTED]
A goggle search on news related to Ipswitch shows they have
gotten two of their press releases printed publicizing the
brilliant move by Ipswitch in Going Pro and Taking on
Exchange. Im sure the MBAs are delighted with the self-
congratulatory free marketing they are getting from these.
But,
Title: Message
They
go in the body because ... that's where they go.
Take a
look at a message in your spam folder. The header ends where you see a
blank line (two carriage returns, or two line feeds). The attachment type
line descriptions do not appear in the header.
I
don't understand
When an E-mail comes in multiple parts (boundary listed in the
headers), each segment should have it's own Content-Type so that the
mail reader knows how to display it properly. For instance, most
personal E-mail comes as both text/plain and text/html in the same
message, but you generally
Essentially the good folks at Enron and WorldComm brought us the
Sarbanes-Oxley Act or SOX for short. Public companies have to keep a record
of all communications, the details of this are vague but mostly apply to the
money people and decision makers. Since we cant selectively catch that
I will look into those, the boss wants me to do this on the cheap,
the sql idea was first so we could at least say we were archiving
the email.
If you just want archiving for independent audit and to show good
faith, concatenate the Q and D into an envelope-preserving MBOX for
Title: Message
Ok they're being displayed in the headers using Outlook
Peek.
Anyway...
For some reason the filter isn't
logging/catching.
If I paste the text:
Content-Type: application/vnd.ms-
Into
the body it will catch.
But if I attach an XLS file it won't even
though the string:
I have an application that acts as a POP3 mail client and writes the message
body (with basic header info) to disk as a .txt file.
I drop them into a folder hierarchy based on the date, etc which Microsoft
Index server indexes (free w/ Windows).
Just look for the message via a query based web
Title: Message
OK... If you haveSTOPALLTESTS in a filter in place of
a weight, does that prevent the current failed test from being
logged%TESTSFAILED% ?
If so I think that's what happening.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark E.
SmithSent:
Mabry Internet/X Controls has a very good Mime processing
controls for easy reading of uue files.
- Original Message -
From: Matt [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, October 27, 2004 3:53 PM
Subject: Re: [Declude.JunkMail] Determining a BCC Recipient
That's funny
If it were me I would just use the CATCHALLMAILS feature of Declude and COPY
them to an archival e-mail address and then just burn the inbox of that
address to disk once a month.
- Original Message -
From: Rick Davidson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, October 27,
If it were me I would just use the CATCHALLMAILS feature of Declude
and COPY them to an archival e-mail address and then just burn the
inbox of that address to disk once a month.
For low-volume and unregulated businesses, perhaps, but this will not
accomplish compliance, since:
- it
Why not just turn the Archive feature of IMAIL SMTP on and route that way?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dan Geiser
Sent: Wednesday, October 27, 2004 5:20 PM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] Determining a BCC
OK, fine then. Don't do it every month. Pick the archival frequency of
your choosing. And can't you use Declude to insert the routing information
into the headers? And can't you download the e-mail from the inbox into the
mail client of your choosing and archive it that way? Anyway, as usual
And can't you use Declude to insert the routing information into the
headers?
Not without compromising BCC recipients, which is unacceptable.
And can't you download the e-mail from the inbox into the mail
client of your choosing and archive it that way?
Possibly, but that's an
I strongly recommend that you just simply keep these in their Q* and D*
formats and zip up the directories every night and write them to a CD or
something every so often. Retrieval of such E-mail should be rare if
ever necessary, and you can easily write something that would unzip the
files,
After all these suggestions I think concatenating the Q and D file and
maintaining a text file is a much better way to go, dtsearch definately
looks attractive.
Thanks again for the suggestions.
Rick Davidson
National Systems Manager
North American Title Group
-
- Original Message -
FWIW, that second link is a story on WhatsUp Pro, not ICS.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Wolf Tombe
Sent: Wednesday, October 27, 2004 4:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] Declude and Ipswitch ICS
A goggle
I strongly recommend that you just simply keep these in their Q* and
D* formats and zip up the directories every night and write them to
a CD or something every so often.
Like I keep trying to say, this isn't an every so often or
best-effort regulation. It's strict and for-real.
.
By design, STOPALLTESTS should stop not only that filter, but also all
other filters that appear after it within the Global.cfg. I'm positive
that this is the design, however I haven't used it to see if it actually
works.
Matt
Mark E. Smith wrote:
Sorry for the repeated posts but I think my
Sorry for the repeated posts but I think my question might have been lost in
another thread.
I'm working on a BYPASS Filter to identify ham. But I'm running into a
problem.
It seems that if STOPALLTESTS is used in place of the weight like:
BODYSTOPALLTESTSCONTAINS
Please don't parse my words so carefully. Each company is different
and therefore so are their needs. Many that archive will never need to
go through the data, primarily because many companies aren't so
enormous that they have the legal liability nor the volume that would
necessitate a
50 matches
Mail list logo