On 23/04/2008, Gordon Messmer <yiny...@eburg.com> wrote:

Since the filter doesn't try and share a connection between threads my interpretation of the reference is that, provided you link against libmysqlclient_r, you don't need to do anything further special.

The global variables that are accessed by the threads are only read, not written to. They are set up as part of the initialisation, the filter does not start listening or launching threads until initialisation is complete. I have never found any need for mutexes to control access to read-only data. Read-write is, of course, a completely different matter.

Good point. Will fix.

Fair comment. For my server installation we currently only use LOGIN authentication but this should be easy to fix.

I don't think I'm treating AUTH:LOGIN as if it were a header, based on my observation of what Courier seems to do, it appears that AUTH:LOGIN is interposed amongst the parts of the "Received:" header - usually on a continuation line.

I would accept the criticism that the AUTH:LOGIN recognition code doesn't really understand headers and, worse, carries on looking for AUTH:LOGIN in the message body if it didn't find it in the headers.

Is there a definitive statement on the location/syntax of "AUTH:LOGIN" anywhere? I can't see it in RFC2822/2821.

Thanks for spotting that !

Left over debugging !

Will investigate. Thanks for the reference.

The point about PGP and SMIME is a fair comment, but I find it difficult to imagine a signing system that would both satisfy end user requirements and not break such things.

Yes at the moment it signs any text/plain and text/html parts. The point about attached text files is a good one, I will investigate further.

Once again thanks for your comments which have probably saved me a lot of time.