Sorry for jumping in late to this thread.. But, I currently run SA3.18 with a similar yet different Exchange Sink and have no such problems as the original poster.
Steven > -----Original Message----- > From: Loren Wilton [mailto:[EMAIL PROTECTED] > Sent: Monday, August 13, 2007 5:28 AM > To: users@spamassassin.apache.org > Subject: Re: MS outlook can't read parsed email... HELP!! > > >> output file. Then i followed instructions and installed > Exchange SMTP > >> Transport Event Sink provided by christopher > >> > lewis(http://www.christopherlewis.com/ESA/ExchangeSpamAssassin.htm). > >> OE is stilll able to read the output from the > sample-spam.txt when i > >> tested it > > Ok. Here's a theory. The last modification Christopher > shows is Feb 2006, well over a year ago. Since then SA has > been modified to always output the same CRLF convention on > output that it got on input. Previously I believe that it > amost always only output an LF between most lines. I'm > guessing that that sink is expecting Unix LF delimiters on > input from the SA output temp file, and is converting the LF > to a CRLF. Since there is already a CRLF, this is resulting > in either a CRCRLF or two CRLF pairs separating each line. > I wonder if the user is actually running SA3.19 or some other version like 3.02? As I recall, that version (I think) had a major bug for CRLF that majorly messsed with Outlook email. (I had to write a work-around function for a while until I installed a bugfixed version (I think 3.11). According to my notes, the problem I think this is related to is bug 4363 (and as of version 3.11, I no longer needed my "work-around" code). > I looked at the source code, but it is rather cryptic VB. > Unless you have the docs on the functions he is calling, > there is no way to guess what half the parameters really > mean. There is probably a nice simple one-line fix somewhere > in the source for this problem. Unfortunately it isn't real > obvious where to put it or what it would be. > The VB from Chris Lewis' ESA Sink uses the ADODB.Stream object. It's required for Exchange to properly parse the message back after it's been dumped out to a text file. (I use the same functions in my own code, so I know). I would highly doubt that Chris Lewis' code is messing with the mail because it is just reading the mail message as it is stored in the txt file (as parsed through SA). Again, I am really wondering if SA is an older bugged version. Is there any chance that the original poster can reinstall SA with version 3.19? And/or 3.18 because my system works well with 3.18. > Since he seems to be calling a bat file to run SA and > redirecting stdin and stdout, it would probably be possible > to write a little 5-line C program that would strip CRs out > of the SA result on the way to the temp file he is creating, > and then things might work. I suspect there are probably > stripcr stream utilities sitting around on the web that will > do this without having to write one. > I guess I would consider a sed, awk, or chmod or other equally useful programs/functions just as cryptic as the COM code that you say is cryptic if I didn't know how to find the documentation. :) > Short of managing to get in touch with the author of the sink > and getting him to fix it, or trying the stripcr trick in an > appropriate bat file (more easily modified than the VBS > stuff), I think you might be best off trying to find some > other way to integrate SA with Exchange. I know one common > trick is to put a Linux box in front of the Exchange server > and route the incoming mail through SA on the linux box, > then feed it into Exchange. Of course, this won't move > things to separate folders for you, but it would get it > properly tagged. > > Loren > > > >
