Ben Lentz wrote, On 29/10/06 3:49 PM: > I guess the real way to fix this is to try and detect the header > delimiter from the first few lines in the message and apply that same > delimiter later on? > > Does anyone have any tips on helping me convince Anthony that this > problem exists?
I think that both problems - how to fix it and how to convince Anthony - are simplified by one big difference between SpamAssassin and milter-spamc. We have to handle mail that may be extracted at any stage of going from one MUA to an MTA to another MTA to another MUA, on any platform. We make some assumptions about compliance to RFC2822, but that only works to the degree that various MUAs and MTAs happen to use something close to RFC2822 for their local format. If that means that we have uncertainty about the newline being used in any given installation, we have to deal with that when adding headers. That's why we can't tell what newline to use without looking at some of the newlines that are already there. On the other hand, milter-spamc is a sendmail milter, which means it only has to deal with the realities of newlines in the headers that are given to milters by sendmail, and can assume a unix-like platform. I notice that documentation for the sendmail milter API says for the function smfi_addheader in http://www.sendmail.org/doc/sendmail-current/libmilter/docs/smfi_addheader.html To make a multi-line header, insert a line feed (ASCII 0x0a, or \n in C) followed by at least one whitespace character such as a space (ASCII 0x20) or tab (ASCII 0x09, or \t in C). The line feed should NOT be preceded by a carriage return (ASCII 0x0d); the MTA will add this automatically. That's just an indication, but here is what I think the strongest argument for Anthony is: Take a look at the newlines in the headers that milter-spamc is receiving from sendmail. If they are unix-style newlines, then that is proof that sendmail is using unix newlines instead of RFC2822 newlines at that stage of the processing, and you have to do the same to keep the results consistent. -- sidney
