Lloyd Zusman writes:
Sam Varshavchik <[EMAIL PROTECTED]> writes:Lloyd Zusman writes:[ ... ] Well, there were simply two newlines (character \n, or 010, or 0x0a) and nothing else in the original message between the last header line and the first multipart separator. I have double- and triple-checked this. What else could be triggering this case?There must be something else. For some reason the parser did not see the blank line, and continued to process the next couple of lines as part of the message header.I agree that there must be something else, but I don't understand the parser well enough to know what it could be. That's why I'm asking these questions here. You're the expert on the parser, not me. Are there docs about the detailed operation of parser? Or if not, could you perhaps point me to the appropriate code? ... maybe I can figure it out via reverse engineering.
The code is very old and is not exactly something that I'm proud of. If you open submit.C and search for "readline", you'll find where Courier begins reading the message.
But, again, I would not lose any sleep over this. This is not going to happen with legitimate mail, only misformatted spam.
pgp0plHg43o5n.pgp
Description: PGP signature
_______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
