NICE! 

Thank you Martin!

Download Url is: http://community.pmail.com/files/folders/utils/entry50229.aspx

Clarifies that folders to be split up, MUST be in Pegasus Mail directory structure and defined in Windows Registry in NewMail sub-key. Also raised the limit on number of messages to 64,000.

Martin,

I don't know what version of NotSplit I have at the office but I've always copied the NotSplit executable and the target .PMM file to the same directory then ran it.  Are you saying this will no longer work with v7+?

BTW, thanks for putting the extracted .cnm files in a \notsplit subdirectory (this tidbit was posted on the PMAIL listserv list).  You specifically mention c:\temp\notsplit in that post and not system temp\notsplit.  Please clarify if it's c:\temp\notsplit or %temp%\notsplit.  If c:\temp\notsplit, does c:\temp need to exist first?

Edit: My tests of NotSplit8 are producing zero byte .cnm files and one file more than the number of messages processed.  Anyone else seeing this? 

As for my questions above, NotSplit uses the value contained in the registry key that holds the path to the mail directory of the last run instance of Pegasus Mail.  As for the extracted .CNM files, they are located in a \notsplit subdirectory of the system variable "temp".  Default in Win7+ will be C:\Users\USER\AppData\Local\Temp\notsplit.

I am now working on a new alternative method of extracting messages from folders.  Please don't download Notsplit V8 until I resolve this.

Martin

Hi guys,

I don't have a clue what I could need the NotSplit tool for and why it is named "NotSplit" since the tool extracts all mails from a folder back into single mails. Is it for achiving purposes?

I could also simply move mails back to the inbox and all mails are saved in single cnm files again. Please give me a hint. Maybe there is an interesting purpose I'm never thought about.

What I still need more is an opportunity to subsequently extract/delete attachments from Pmail folders. Some days ago (always at the turn of the year) I have checked the mail folders of all of my users. And again and again there are big folders with a size of nearly 2 GB. Though they save attachments at the file server, they forget to remove them from the mail. I'm not interested to remove each small attachment like signature pictures/logos. But when sorting user's mailfolder by size, there are a lot of mails with attachments of about 30 MB! And this causes to very big mail folders. A small tool which is showing me the biggest chunks within a folder and where I could select attachments for removal would be very nice. At the moment I have to move the biggest mails back to the inbox, deleting the attachments and move them back to its destination folder. Lot of work. But maybe we discussed this problem already in past.

Greetings

Answer to your last question.  Notsplit is called that because of 8.3 file naming from ages ago, it should be NOTESPLIT.  Feel free to rename your copy.

As for why to use Notsplit.  Two simple answer.

1. Folder exceeds 2 Gb  and probably should be split up by some category, as this is the maximum size allowed.

2. Folder is damaged beyond repair, usually because folder and index are out of step and cannot be rebuilt.

As for your other comment on attachments,  I already have this utility, but have not rushed to make it available, as upcoming Pegasus Mail V5 has a new folder structure   (Sqlite base I believe).   Also there are several tools already available in Pegasus Mail that will list all the folders with their file sizes.  I would suggest you look at PmailUndup and examine folders with large sizes, which identify recipients of large volumes of data (not signalling whether it is large html streams or attachments.)

Hope that helps.

 Martin

Joerg,   Just a quick question,  you mention people with attachments of 30 Mbs in messages.  I don't know how to imbed files of that size inside a Pegasus Mail message. Using clipboard to load the message area is not possible.  My expected way would be to provide a Url that the recipient could access to download such a file. Otherwise, the only way would be to use the standard Add Attachment, which would require the file to be encoded with Base64, which increases the file by 30%, to make it even bigger. That being said I don't know how any ISPs would allow such a transmission. That kind of transmission would more likely use FTP or similar utility. The only other way I know of, is to use the Data: protocol within a IMG html statement, which is intended for small files up to 800 bytes ie: (* <img src="data:image/png;base64,iVBORw0KGg   the last portion of this example (iVB... is Base64 encoded *)

So I would like an idea of the message structure being used for such huge messages please,.  My utility does not handle such enormous data streams.

Thank you,

        Martin 

Google Mail (gmail) allows for 25mb file attachments. This would work via IMAP to another gmail user, yet most ISP would bounce/reject.

GMX allows for 50mb file attachments to e-mail messages. From website:

With 50 MB attachments you have the possibility to email large files like documents, lots of photos, and videos! With other email providers you are limited to 20 MB attachments. GMX has raised the limits so you can send larger files! Email large attachments and share the best moments. Send large files up to 50 MB - it sounds so great! 

Runbox allows for 100mb file attachments  - from website:

What is Runbox’s limit on attachment sizes?

There a a few mail providers that allow for rather large attachments.

gmail - 25mb

GMX 50mb, from website

Send Large Files with GMX's 50MB Attachment Limit. With 50 MB attachments you have the possibility to email large files like documents, lots of photos, and videos! With other email providers you are limited to 20 MB attachments. GMX has raised the limits so you can send larger files! Email large attachments and share the best moments. Send large files up to 50 MB - it sounds so great!

Runbox: 100mb, from website

Remember, however, that your files will grow in size by approximately 33% when you attach them to your emails. This is due to the encoding process that is necessary to allow files to be sent as email attachments. This means that the maximum unencoded file size you can send using the Runbox email service is roughly 100 MB. 

Got to love standards, so many to choose and abuse from.

Hopefully this appears once, tried quick replay and nothing displayed. 

Hi Martin,

We have to exchange many documents with our customers, including big ones. Since a few months therefore we've created a https encrypted up-/download webspace for our clients. But most of our clients would prefer the easier way - E-mail. In addition, always creating a separate webfolder (at our https exchange system) for each client including separate access credentials would be a neverending task (we got hundrets of clients). Insofar clients are still sending big files by e-mail every day.

But I have limited the outgoing way via Pmail/Mercury. My users may send e-mails of 15 MB maximum size and get a warning message when attaching files of more than 10 MBs. I would like to train them to use the https exchange. [;)]. FTP is nearly dead. We used it in past but nowadays only very rarely.

From our ISP the sending of mails with such big attachments is no problem. We could attach files up to 50 MB.

Hope, you could imagine, why I'm interested in a tool for subsequently removing of big attachments. But this tool should not remove any attachments without asking. Rather it should list all mails of a selected folder, sorted per size, where I could select single mails for removing of attachments.

Cheers

Joerg

Joerg,

     Thanks for the clarification. It seems there are two programs involved. The first simply lists the messages by decreasing size, identifying them, so the second program can extract them one by one, leaving a trail marker to tell the reader of the extraction, and where to go to get it.  For example, "Attachment was removed for this message, because of size, and can be found and kept, moved or deleted, when appropriate from c:\pmail\mail\extracted".   In the case of the first program I would like some idea of the triggering size for a message to be reported. Otherwise these could be hundreds, or thousands of messages to ignore on a large list. This program just obtains file names and sizes from the *.PMI index file. The second program works on the matching *.PMM message folder. 

I have the first listing program just about ready, right now, and will ship it to you shortly

Comments please ?

Martin

Hi Martin,

Thanks for your interest. Sounds good so far. Regarding the triggering size I would prever a combo box where I could choose from different values, e.g.:

List all mails in decreasing order with attachments

> 20 MB

> 15 MB

> 10 MB

> 5 MB 

This would complete satisfy my needs.

Jeorg,

   Could you please send me your email address, and I will send you my first attempt (folderRep.zip). There is a readme (FolderRep.txt) but it is quite brief. The example CSV file can be sorted by descending Size or by Folder name.  I assume the folder directories are in the standard location, c:\pmail\admin\newmail

 Martin (irelam17@telus.net)

Jeorg,

   Thanks for the email address.  Just one issue to resolve. When reading through a folder of messages I found that the majority of attachments are either Base64 or Quoted-Printable (Q-P) encoded, with no file size. The only time a Size is given is if the file is "inline" on the Mime Content-Disposition statement.  

So,  I see that for all practical purposes I need to count all the bytes between the Mime part headers and the terminating boundary. The active size is actually not including the CRLF pair at the end of each line of Base64 or Q-P encoded data.   So for multi-megabyte files this would be a substantial number (2 bytes for every Base64 line, every 10 Mbs would have 125,000 CRLF pairs = 250,000 bytes .  So my question today is should I quote the full size encoded, as it is the space required to store the full message encoded ? That would indicate more accurately the savings if the attachment is removed.

Martin

Hi Martin,

[quote user="irelam"]Thanks for the email address.  Just one issue to resolve. When reading through a folder of messages I found that the majority of attachments are either Base64 or Quoted-Printable (Q-P) encoded, with no file size. The only time a Size is given is if the file is "inline" on the Mime Content-Disposition statement.

So,  I see that for all practical purposes I need to count all the bytes between the Mime part headers and the terminating boundary. The active size is actually not including the CRLF pair at the end of each line of Base64 or Q-P encoded data.   So for multi-megabyte files this would be a substantial number (2 bytes for every Base64 line, every 10 Mbs would have 125,000 CRLF pairs = 250,000 bytes .  So my question today is should I quote the full size encoded, as it is the space required to store the full message encoded ? That would indicate more accurately the savings if the attachment is removed.[/quote]

How Pmail is discovering the file size of each mail, which is shown inside a Pmail folder? When starting, does it also run through all files, counting all mail sizes in your way?

But anyway, I know that each mail will be encoded before sending and that its real size is increasing by up to 30%. But I'm not so skilled in the different ways of encoding. But I could imagine that counting all CRLF pairs in files of about 1 GB could be a high time consumption process, isn't it? At the end I'm not interested in the exact size of an attachment. If there is an e-mail with an attachment of e.g. about 20 MB, it doesn't matter whether the tool would show 19.8 MB or 20.3 MB or something like that.

To your question: Yes, from my point of view you could quote the encoded file size, since this is the real used space we could save.

Thanks.

Joerg

Jeorg,

  As far as I know the only sizing that Pegasus Mail sees is the total msg size(SMTP/POP3/IMAP) from the incoming message. its only interest is when the message is moved from the NewMail directory to a folder and the bytes transfered are recorded in the folder index (*.PMI). There is no recording of individual message parts sizes.  "inline" content-disposition Mime headers can contain a "Size" value but this imformation is not displayed. So counting lines and accumulating lengths is the only way to go.    So I am creating the grouped size list with the values you are suggesting, but I will allow for editing the list at some point. So the message total size is recorded as the message size, not the attachment size, to base possible attachment removal on.

I have found that reading each folder content and parsing each note is very time intensive. At present I am including messages that have been marked Deleted, as the size of the folder does not go down until a compress is invoked, which removes these items.  Also I am skipping any message that is marked, Encrypted, as I can't see any Mime parts or data, except the message header lines. Only single part messages could be counted. 

I am validating my reports right now, to see if I am handling all conceivable conditions.

Won't be long, I hope

Martin

Notsplit available again. For those of you that downloaded the previous version please use the following link to update your current version

Please see Notsplit8.htm in the new zip file for info on process and locations.

http://community.pmail.com/files/folders/utils/entry50294.aspx

Martin