BTW, I have to throw away lines occasionally because of intermittent CRs that cause problems with parsing. For my log parsing, I initially tried to use SQL Server DTS to isolate fields and parse from there, but SQL would merge two lines together at times because of a related problem with EOL characters. A separate parser is doing better, but still occasionally has to throw away lines.
I'd like to add my vote to the others for ironing out the few bugs in logging.
FWIW, I'm not aware of any bugs with logging (as of the latest interim, which fixes an issue where two lines could be combined if certain control characters appeared in the subject).
There are, however, two issues that I'm aware of. [1] A problem where a flaw in Windows will incorrectly cause corruption to the log file (such as multiple lines getting mixed together), which affects any programs that use multiple processes/threads to save data (including IMail), and [2] The desire for more flexibility in logging (such as choosing whether or not "Msg Failed" lines should appear in the log file). We're looking into the possibility of changing the logging to bypass the corruption program (by having a centralized process do all the logging), as well as more logging options. However, these are not currently a high priority.
-Scott
---
Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000.
Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection.
Find out what you've been missing: Ask for a free 30-day evaluation.
--- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
--- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
