AUTOPOP[v.7+].nbs ========================================================= Reads FLUSHIT.RER and TOP-OLDS.RER from folders of ReRead-indexed HEADers =========================================================================== Feb'05-Aug'08 (c) REVOBILD Heimo Claasen / Brussels =========================================================================== Script to download mail from POP3 servers with NETBAS (c) Martin Goebbel ------------------------------------------------------------------------ Use:> netbas autopopX.nbs config.filename [ add_bytes | o | z ] This is an again slightly improved version of a script for NETBAS which allows to "recursively" download headers only (and some lines of the body) or full eMails selectively with a connection to a POP3 server. A next connection to that server will delete all unwanted, and dowload all wanted mails left with the previous log-on, and dowload headers only from newly arrived (larger) mails, etc. It needs: -- a POP3 mailbox which has the "top" command implemented, -- the setup of dialler/packet driver, e.g. LSppp -- the NETBAS interpreter from Martin Goebbel ==> v.0.34 !!! (see below) -- the offline mail reader ReRead v4.5+ from Revobild (see below for other) -- and DOS, . The basic idea is to reduce both telco time - almost everywhere metered by now - and fees, and bandwidth: which after all, always has to be paid for by someone, and that "someone" in the last instance is YOU. And to reduce own storage space for completely useless stuff, especially of SPAM. The problem is that mailboxes set up with the POP3 protocol offer very limited possibilities to look at what's in the box _before_ downloading megabytes of nonsense. (While IMAP [web-accessible] mail boxes allow to do that, their use again is subject to metered online time and often even to volume fees; and worse, as all IMAP mail needs to be formatted in HTML - often enough done lousy by the mail servers' automechanism -, volume is forcedly bloated by at least one third, often up to two thirds. Thus: IMAP is not a serious alternative to classic POP.) This NETBAS + AUTOPOP combine can limit online time and fees to a strict minimum. The critical work, both in terms of fees and time, can be done off-line and there, even to some degree automatically, e.g., with a clever sorting routine for the items left over at the server for which only headers had been fetched. It goes like this: 1. Get online with the packet driver. 2. Download the package of eMails sitting at the POP3 server, using AUTOPOP.nbs with appropriate settings to get only headers and a first or more lines of body text (especially with "large" items). The script creates two files for the HEADER-only downloaded items: -- TOP-LIST.RER, a list of the number of bytes for each item left at the server, and a -- HEADER.FIL (or whatever you name it in the Autopop configuration) where only the downloaded headers + x(lines) go of the "larger" items left at the server. All the fully downloaded mails - thus not those where headers only were fetched - will be stored in the usual capture file (defined in the Autopop configuration file). 3. Close the dial-in connection. 4. Run ReRead and select the specific header-file created which holds only the headers and the specified number of lines from mails _not_ downloaded. 5. Select - from the index listing or from viewing the items - which of these mails you want to delete at the server, and mark them =d= for deletion. Those _not_ marked for "delete" will be downloaded with the next mailfetch, the "delete"- marked will be erased at the server. 6. Use [F2] IN THE INDEX LISTING of ReRead for this "header" mailbag to create a "flush list" - called "FLUSHIT.RER" - which will be used with the next run of AUTOPOP. -- !! NEW feature with recent RE-READ: command line switch "/f" for ReRead does this automatically - good for batch use. -- Steps 4 to 6 can be done (offline) by any other means (or offline mail reader), provided it results in a file listing the order number of items to delete at the server (i.e., the order number in the bytes-listing of HEADERS only downloaded - NOT the order numer of mails at the server !) 7. Goto step 1, or just use the created batch setup to get/delete selected mails with the next fetch-mail run. Depending on the settings in the autopop configuration file for LARGe mail items, you get: -- a number of items into the ordinary mailbag (defined with the FILE entry in config); these will then be deleted at the POP3 server in the second phase of the same mail-fetch run; -- a number of items with headers and only some first lines of the mail body (the number of body lies is to be defined in the configuration for the script, with the HEADer entry) in another "mailbag" type of file (a name likewise to be defined in config). You can look at these off-line with a mail reader and decide on which of them to download with a next fetchmail run, or to straightly delete them at that next log-in to the server. RISK: ----- The selection of mails to delete _at_the_server_ is based on the precise byte volume of individual mails left there, and from which only the headers have been downloaded, together with the server's declaration of the stored byte volume of each item. An assumption for the whole routine is that there are hardly any two mail items stored at the same time at a POP3 mailbox with _exactly_ the same bytes volume in the [mandatory] "list[ing]" available from that POP3 server. In checking through mail archives of a huge number of items I have found two (in words, 2) examples of two different mails with the same bytes volume, and these from different dates of POP3-downloads. So this seems a sufficient close margin for "false positives". In addition, the routine to delete items at the server takes a first occurrance of that specific byte volume - a more recent incoming item will _almost_ certainly be lower down in the stored order of items at the server, and thus will not be at risk to be automatically deleted. Thus this routine is based on an empirical estimation and does not warrant for a "absolutely safe" exclusion of an accidental deletion of a mail item. It's to accept this (really miniscule) risk, or not. Quite a larger number had been "close hits" with merely a few bytes differences in individual volumes (spanning large differences of download times and different servers). So there is no leeway to have a fuzzy selection of NNNN +/- X bytes; which causes a small disadvantage: When these servers shovel the mails around - which they do, in an unpredictable way and thus changing the order too, sometimes -, then a mail item left over may get a slightly different volume listing at _SOME_ (few, unusually programmed) servers. At the same time, this may cause another type of "false positive" error - while one mail item present earlier can get its volume listing changed, another or newly income item could have precisely that volume of bytes of the former: the selection based on this volume after an earlier listing would thus identify the new item to delete. However, I did not experience one single occurrance of this strange error in the whole test phase, and the use of the script ever since in more than three yearse since.) It's too difficult - and expensive - to do a precise calculation of these risks; they are there, logically, but nevertheless I consider them indeed negligable. Details ------- This improved version of the AutopopX.nbs script is still a bit clumsy to set up, and contains some obsolete routines from the originally all- manual "get-mail.nbs" Netbas script.[*]. However, it uses the same configuration as GET-MAIL.NBS and all earlier AUTOPOP versions, so the transition is a bit easier. Please have a look at the commentary at the beginning of the script, and get the more verbose descriptions for the parent "GET-MAIL.NBS" script available on the website, www.revobild.net. As AUTOPOP.nbs is a "script", it has to be run as an argument to the NETBAS.exe interpreter, and it needs a specific configuration file for each mail(-server, -box) account; like this: netbas autopopX.nbs account1.cfg [switch or number] In difference to the earlier AUTOPOP scripts, there are _NO_ other parameters _needed_ (or allowed!) in view of the mail handling, except (see below) one optional switch: This script is designed to "GET all" mails (with the exceptions of those defined as "too large" in the configuration), and then "DELete all" which had been completely downloaded, or had been marked for deletion from the outset (i.e., after offline selection of downloaded headers); and in this sequence. However, if you set the debug switch ("debg=1") in the configuration file, no mail will be deleted; this may be useful with trial runs to determine the most appropriate settings. A new ALTERNATIVE for this is the "z" switch at the command line: It prompts before deleting any mails at the server. The behaviourwith Selection/downloading is steered by three entries in the configuration file: -- LARG=nnnn (nnnn in bytes, and a positive number) --------- This defines the threshold for items to download or to leave at the server. Setting this "nnnn" to zero ("larg=0") will get all mails and delete them thereafter. Setting it to some positive value will sort between shorter and longer items, download the shorter ones entirely (and delete them therafter at the server), and will download the header _only_ and some (defined) first lines of the mail body into a separate file. NOTE that this is different from the earlier versions where the headers- only downloaded items were included in the downloaded mailbag (and in _addition_ copied to a second, "headers"-file.) -- LARG=-nnnn ---------- Setting it to a NEGATIVE value (e.g., "larg=-12000") will get all mails of a smaller volume than this and will UNCONDITIONALLY DELETE all larger ones then. NOTE that this negative switch takes precedence over a HEADer indication: if set, it does not use the "top m n" command and does not download headers from too large items but just deletes these. This is a - drastic - defence against megabyte-bombs/spams at a POP3 server wich does not allow to look at the headers (i.e., does not have the "top n m" command.) -- HEAD=nn (a positive number for the lines of a mail body to get only.) ------- This defines the length - minimum 1 line - of the part of the mail BODY to get from the server. A meaningful range would be between 10 and 40 lines. With setting the LARGe limit quite low (say, to 200 bytes), and the number of lines to get with a HEADer sufficiently high, you get the header information of the mails stored at the server and some first meaningful elements from the mail body in order to apply all sorts of sorting utilities OFFLINE which need additional information. Bridging between fetchmail runs: -------------------------------- With POP3 servers, the alternative to do such a two-steps online/offline sequence would be to parse and show all the header+toplines information online; which would mean quite a large program overhead (and which is what some of the huge "integrated" mail programs do have - and they leave you all the time online with the meter ticking.) Going offline however, requires some means to transmit the salient information from one connection to a next. For this purpose, the AUTOPOP script uses two files which are created with, and consecutively to, a get-mail run, "top-list.rer" and "Flushit.rer": 1. TOP-LIST.RER --> to be renamed immediately after closure of the server connection to --> "TOP-OLDS.RER": this "hardwired" filename is needed for the next run. Autopop by itself creates a file named TOP-LIST.RER which consists of a list (one item per line) of the POP3-"list[ed]" bytes of each mail stored there and downloaded with the _header_-only command. The items in this list correspond, in the same order, to the mail-items stored in the downloaded items in the HEADER-file. This list _has_ to be renamed IMMEDIATELY to TOP-OLDS.RER before _any_ next run which would overwrite an earlier "top-list.rer" file. --> if any items leftover at the POP3 server shall remain there - i.e., neither are to download nor to delete with the next logon - then ELIMINATE the entry of its bytes-volume in TOP-OLDS.RER _and_ the stored item in the headers-file. (In ReRead, do this before marking other items to be deleted, and re-index the headers-file.) (This is a bit clumsy and I'm always nagged to think about another way to mark items for "keep at the server".) 2. FLUSHIT.RER -- to select the order number of items in the TOP-OLDS.RER list for those mails which are to delete with the next dial-in connection to the POP3 server. This is created OFFLINE, for instance with the mail reader ReRead.exe by pressing key [F2] in the INDEX LISTING submenu of viewing the headers-only mailbag (or mailfolder) index; or automatically with runnign ReRead with the "/f" switch at the command line. This is a (text file) list, one item per line, simply with the order numbers of those mail(-header) items in that bag/folder of headers which are to be DELETED in a next run of Autopop to this POP3 server. With Re-Read, just "=d="-delete-mark in the index list, or from reading the header-item, then press [F2] in index mode, before exiting. (Each keypress of [F2] in the index listing will overwrite an earlier created FLUSHIT.RER.) With another offline reader you can create it by simply typing the order number of mails - according to the LISTING in TOP-OLD.RER (and !_NOT_! the order number at the POP3 server!) - into a file named FLUSHIT.RER. All other items contained in the TOP-LIST.RER / TOP-OLDS.RER list but _not_ pointed to by an entry in the FLUSHIT.RER list will be downloaded completely with the next fetchmail run (and only thereafter deleted at the server), i.e. this switches off the limiting condition for dowmloads for this item. If not _both_ of these two files - FLUSHIT.RER and TOP-OLDS.RER - do exist, NETBAS + AUTOPOP.nbs will run just normally, without deleting leftover items from an earlier turn at the server; you just get all those headers once again, if you had set a limit for the mails to download in the configuration. If only the bytes-list (TOP-OLDS.RER) from the previous headers bag exists but no delete-list (FLUSHIT.RER), these items will be downloaded fully and then deleted at the server. REM: take care of deleting a pertinent entry in that list of bytes of the leftover items (TOP-OLDS.RER) if you want to leave a (perhaps very large) file at the server for which already a first round has sampled the header. (Another clumsiness with the whole arrangement is caused in case there's only one item left on the server and to be deleted with the next log-on - ReRead doesn't "index" a mail-folder file containing only one item. The work-around is to include a step in the batch file for running Autopop which in this case - and prompted for - creates the FLUSHIT.RER file with just the number "1" on the first and only line in it.- The solution for both clumsinesses is more complicated than it seems at first sight; it would additional functions in the ReRead marking and indexin routine, and quite some reconstruction of the core selectio loops in the Autopop script; the latter is time- critical as POP servers cut off after aout two idle minutes, while NETBAS as an interpreter is not extremely fast, and it allows only for one-dimensional arrays: the present selection routine is the already shortened algorythm I know of for sorting/comparing the two arrays for stored and delete-marked items, a third selection - the "keep" mark for instance - would need a third run through the loop; with more than about 250 items in the list of stored header items it runs up to the dreaded *timeout* limit with this slow AT'286 PC. Though this is negligeable with today's CPU which work a bit faster than this dinosaur with its full 25 _M_Hz.) SETUP ----- Now, there is a problem with NETBAS and its (DOS-)handling of filenames: It appears that complete "file specifications" (including backslashes and drive designations, and definitively if this makes up a long string) are not well digested by the interpreter - I had numerous hang-ups with trials to define pathes and filenames in the config-file for AutopopX.nbs, it seemed impossible to pass the complete names of those two source files to the script. The only way out, for the moment, is to "hardwire" those filename.ext[ension] entries without any path specification in the script, and to care for a setup which provides for them being present IN THE (SUB)DIRECTORY FROM WHERE Netbas (with the Autopop script) is run. As it is, AUTOPOP.nbs would be better set up with a batch program anyway, seen that it needs -- the configuration file for a specific POP3 account; -- the list of volumes of mails left at that server, TOP-OLDS.RER; and -- the list of which ones to delete there, FLUSHIT.RER, the next time; -- one capture file for the ordinary downloaded mails; -- a distinct capture file for the copies of headers-only downloaded items (from which the list of items is derived to define either deletion or download with the next run). This header-mailbag can and should be deleted after the selection is done which of those items were to download or to delete; As the names of those two files needed for " bridging" are "hardwired" without any d:\path\ in the script,[**] they should be present directly in the directory where Netbas + Autopop is run from, as well as the configuration file, but they should be stored and saved in a distinct (sub)directory to avoid being written over with a next connection to an other account. This needs a little (though fairly simple) batch arrangement. But first about the entries necessary in Autopop's configuration file: CONFIGURATION: -------------- Autopop _requires_ a configuration file containing some entries for the connection with the POP3 mailbox server. For details see the commentary lines in the beginning of the script. Specificly for AUTOPOPx, the following entries must be set: head= -- a (positive) number, at least "1", which is the default set in the script, for the number of lines from the _body_ of a mail item to get larg= -- a (positive) number for the bytes limit for LARGe mail items _NOT_ to download (but only their headers). or, larg=<-nnn> -- a NEGATIVE number for the bytes limit for LARGer items than this where even a header is not to download _AND_ this item is to delete directly. hfil= -- the name of the file those header- only items are to be stored in. AUTOPOP does not need, nor use, other command line arguments than the name of this config.file (except for the optional addition of a bytes- number addition, see below.) Thus if you have used earlier versions of the Autopop script the things to eventually change in the configuration are: -- do not set LARG=0 as this would disable the limiter switch for to get only the headers; -- the LARGe= must not be negative _if_ you want to get at least the headers of those too large mails sitting at the server; a negative value takes precedent and would straight delete the item at the server (see the script logic for this, in the "main task" section). It's to play and experiment with the various settings. With one especially SPAM-infested account I do use a negative LARGe value of 12000 bytes for effectively trashing almost every "attachment"-bloated mail in the first hand - those correspondents using (still) this address know to not sending bloating "attachments", and would almost never risk to pass this limit. With a positive setting to the same value I never found any mail item _there_ which would have been worth downloading. In addition, this account doesn't have the "top n m" command implemented by the (mean) ISP, so it's no choice but to either get all the trash or risk losing an (extremely rare) valid mail item. This in contrast to another account where indeed volumes of mail bodies, as well as the legitimacy of attachments, vary largely (and demand individual assessment.) As this account does offer downloading haeders+lines only, i.e. it has the "top n m" command implemented indeed, I can set the LARGe limit quite low and can sort and evaluate the rest offline for eventual meaningful download of some leftovers with a next dial-up. OPTIONAL COMMANDLINE SWITCH: add-"[number]", or "o" ---------------------------- This had been added to cope with one specific POP3 server's somewhat idiot properties: After a first log-on, this server up-numbers the byte volume of stored (and not dowloaded) mail items each by 10 bytes. After a second logon, these byte-volumes of leftovers - the numbers of which are downloaded with the "list" command -, _or_ after a longer time period, are _once_again_ increased by 1 (byte) at the server. Heaven knows why (a question for an explanation has not been answered by this ISP); it's surely some sort of weirdness but seen that they have a rather current server, something like this may happen at other POP3 servers too. (Someone who'd have an idea about this bizarre behaviour ?) So I added this switch which can be conveniently employed in a variable way from the command line, without searching/editing in the script: I just add the number - "10" in the usual case (of a rather immediate) second connecting to this POP3 mailbox, or "11" when there had been a while between log-ons - on the commandline of the _batch_ which does the fetchmail run with this account, and inside the batch - at the pertinent command line - is a DOS-template for this number: > [call] account1.bat 10 ---- inside batch "account1.bat":--------- ... ...> netbas autopop.nbs account1.cfg %1 ... Sometimes there are new mails at the server which arrived between these log-ons and are not seized - either for download or delete - at a third log-on, despite of having been marked for either of the actions at the second log-on (because their upnumbering at the server is out of sync with the two steps this is done, and the [added-number] employed; nothing to do then but to get at them in a fourth fetchmail run without any modification of the byte listing - at that state these items' "list"ing would have become stable, hopefully. (REM: "1st / 2nd / 3rd log-on" used here to make it simple; as the procedure is in a way recursive - if there _had_ been leftovers -, any "2nd" is in fact a "first next" logon, a "3rd" a "then next" logon, etc. Easier to figure it out mentally, as kind of a loop until the box is emptied, than in a written description.) In some months of dealing with this erratic server serveral times daily I never accidentally lost any mail; but I had to go on to a (relative) 3rd logon quite often, even a sequentally 4th re-logon to it was needed from time to time. The "o" switch: --------------- But each re-download implied to go through that boring list of mostly spam again, so finally (Jan'04), I got enough of it and (re-)installed another switch, to be used _alternatively_ to the one for byte numbers to add: This switch is just the letter "o" (lower case "oh"), for "order", and it uses simply the order number (from FLUSHIT.RER) of the items left at the server, to define the delete-markings. THIS IS A RISKFUL choice: ! Between log-ons, the order number at anny POP3 box may change ! Luckily, many ISPs have their POP3 servers setup to add newly incoming mails at the end of the queue, and do not change the sequence of mails stored when one or the other item has been retrieved/deleted; so it is a somewhat useful option - as in the case of the weird byte-volumes changes at that ISP mentioned - but one has to observe the server's behaviour closely; e.g., do some retrieval of only a few mails and leaving the rest at the server, then compare the sequence at a next logon. FOR TESTING AND DEBUGGING: The "z" command line switch -------------------------- As a shortcut for testing (and to avoid the more verbose output with the "debug" entry in the configuration file) there is the "z" switch which causes a prompt before actually doing the deleting phase in the connection ONLINE with a POP3 server: The script will run the get mail /get headers tasks and then prompt for continuing - or not - with deleting dowloaded or delete-marked items. BATCHED SETUP: -------------- The need to "hardwire" the input files names (FLUSHIT.RER and TOP-OLDS.RER) in the script makes for a somewhat clumsy but simple setup in a batch file to run the whole thing, if there are several mailboxes to check in a same run: For each of them, the lists of bytes of leftover items and of the order-numbers for which to erase, have the same names, respectively - thus they must be stored in different sub-directories and re-copied to the current directory (from where Netbas is run) just for the instance of connecting to this specific account. The following part of a batch file is the example I use: the entry for the header-file for downloads from Account_1 in the AUTOPOP configuration file "mail-ac1.cfg" is "head-ac1": ------------download.bat running in DIR1-------------- @echo off echo. :Label1 echo Account 1: ********************************************************** ) This is just to make sure no ) earlier files with these ) names are left over: if exist top-list.rer del top-list.rer if exist flushit.rer del flushit.rer ) Any bytes-list file and the file ) with their order number of those ) to be deleted have to put into the ) current directory: if exist .\subdir1\top-olds.rer copy .\subdir1\top-olds.rer if exist .\subdir1\flushit.rer copy .\subdir1\flushit.rer ) run NETBAS: netbas autopop.nbs mail-ac1.cfg ) Next is a usefull safety belt - ) if there is a connection problem ) the script will create a one-line ) file, "apop-err.!!!". Ending the ) batch here spares to re-do the ) mail-run to do the selection: if exist apop-err.!!! goto Ends ) The header-file created with a ) previous run and its index can ) now be deleted: if exist .\subdir1\head-ac1.ext del .\subdir1\head-ac1.ext if exist .\subdir1\head-ac1.idx del .\subdir1\head-ac1.idx ) And the output of the mail run ) saved to the specific sub-dir: if exist head-ac1.ext move head-ac1.ext .\subdir1\ ) The first following line just to ) avoid an error (message) from the ) DOS batch - there may not be any ) top-only downloaded items: and the ) next line then is needed to save ) any such bytes-list under the new ) and likewise "hardwired" name: if not exist top-list.rer goto Ends copy top-list.rer .\subdir1\top-olds.rer del top-list.rer :Ends if exist flushit.rer del flushit.rer ) ( - Not _really_ needed, but...) :Label2 echo. echo Account 2: ********************************************************** etc. ------------end example download.bat running NETBAS in DIR1-------------- There are perhaps more elegant ways to write such a batch file but this one works as it should. The salient point is to have the pertinent TOP-OLDS.RER and FLUSHIT.RER for the specific Account_N in the current directory from which NETBAS + AUTOPOP is run. In addition to this basic batch pattern I use a sort of looping batch which - still online - runs the offline reader ReRead through some of the various subdirectories for the number of mailbox accounts checked, and goes back connecting to (some of) them with NETBAS + AUTOPOP to definitely get some of those items for which the earlier run only got the Header file. (Note - and watch out for ! - that all download files are opened in the script with the safe "a" switch to always _append_ new data written there.) In practice this goes quite fast with the half dozen email accounts I check regularly. And it saves me certainly tons of SPAM - and more and more of that gets overbloated to incredible volumes - to ever download. Q.E.D., ========================= WARNING NOTE ABOUT NETBAS ========================= The most recent version ("Netbas34.exe"), date stamped 8 Dec 2002, has important improvements in its TCP/IP stack handling - so this version is decidedly to prefer against earlier ones. However, and if you ever want to play with scripts for it, be warned that there is a bug in the parsing/working of GOSUB labels. In addition, there is a highly error-prone inconsistency in the syntax in that respect that ordinary labels (to jump to) must have a colon but must _not_ be called by their name _with_ a colon; while GOSUB labels need to be called _with_ a colon after their name. This makes it highly recommendable to _not_ use the GOSUB mechanism at all, or check thouroughly if it works, and how. Further there is this problem with path specifications with string$ for files to open. Other parsing traps are in the one-line "if...then ..." statements (which choke easily already with simple expressions: better use the block if/[else/]endif format thoughout), and the risk with commentaries following on a same line with a statement and which contain some operator or syntax elements: better set comments throughout on proper own lines. Regrettably, this forces to use a lot of GOTOs and thus, spaghetti code - see this example... And more serious: It is not given that scripts written for earlier NETBAS versions will work properly with this one ! Generally it's rather irritating to debug scripts as Netbas has only a very crude (syntax) error checking; and the most important tasks need the net and server connections running - with really panic provoking results, in the event of a script fault: the whole "live" memory can get filled up and severely upset[***] - I guess the writing of this script needed more than a hundred dial-ups (each metered at EUR 0,15 in themselves, and with additional metered connection time), and has produced some good dozens of serious crashes. Frustrating. But I estimated my break-even point in the savings alone of telco fees to less than two month. So that wasn't too bad, . ================================================================== [*] GET-MAIL.NBS astonishingly does still run with the newer Netbas versions, nevertheless. (I could not find out why the gosubs used there do _not_ offend the interpreter...) It can be run all-batched (with all sorts of command line arguments for the switches) or "all manual" as sort of a "dialogue" tool with the POP3 server. Use this latter mode to test the commands implemented (or not) at the mail account. [**] Though you can change these "hardwired" filenames yourself - Netbas scripts have to be pure text-only, anyway. [***] Luckily, I had NO damage to the _file_system_ EVER. (Yet.) At worst there were some "lost clusters" from downloaded files which were not orderly closed (make sure to do the latter _before_ any breakpoints which in turn must be "hard-written" into the script: there is no other debugging manner available with Netbas.) At cause with those crashes are both Netbas and the packet driver - that latter continues working, in a highly erratic way, when Netbas has crashed. At cause too is the C language in which both are written and which is notoriously bad with handling memory securely, especially in situations where string buffers can be accidentally overwritten. -hc =================================================================== Aug'08 (c) REVOBILD Heimo Claasen / Brussels ===================================================================