Whoops...missed the Msg Failed lines were moved to LOGLEVEL HIGH in 1.78.
Still would like input on the CR CR LF problem, though.
Darin.
----- Original Message -----
From: "Darin Cox" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, February 29, 2004 5:43 PM
Subject: Re: [Declude.JunkMail] Possible Missing JM Log lines in 1.75
Hmmm...I'm seeing occasional control characters in non-subject lines, as
well as the EOL problem where the CRLF gets mangled.
However, I'm not seeing the mixed lines problems that others have
reported...probably because of lower load on our system.
I've attached a few log snippets to illustrate the problems I'm seeing. In
every case, it seems there is a CR, and then a CRLF. I don't see a matching
LF to the initial CR anywhere. This screws up the SQL Server imports I
attempted previously. I can bypass the lines with the parser, but proper
parsing would be preferable. If we can't get it fixed, I suppose I could
read the log in chunks as opposed to line reads...
I tried 1.78 briefly, but it broke the parsing I had in place to look for
"Msg Failed" lines and parse for "Action="...makes it a little more
difficult to separate out HOLD vs. DELETE...though we could look at the
actual tests failed instead.
I'd like to propose that log formats have dedicated lines for the most
commonly used information, and restrict enhancements to adding new lines for
more information rather than changing existing lines. That way those of us
with log parsers have some stability in our reporting.
Appreciate it.
Darin.
----- Original Message -----
From: "R. Scott Perry" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, February 29, 2004 4:22 PM
Subject: Re: [Declude.JunkMail] Possible Missing JM Log lines in 1.75
>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.
_____________________________________
[This E-mail virus scanned by 4C Web]
---
[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.
