On 23/04/2008, Gordon Messmer <[EMAIL PROTECTED]> wrote: > Peter Burden wrote: > > > On 23/04/2008, Gordon Messmer <[EMAIL PROTECTED]> wrote: > > > > > > > Peter Burden wrote: > > > > Since then, I've cut some code and have a working signing filter. > > > > If anybody wants to have a look and let me know about any bugs > > > > (obvious or subtle), source code is at > > > > http://web.ptwol.net/sigfilter/sigfilter.c > > > > It's in standard C and uses a MySQL database. > > > > There are some explanations of how it works in the source code. > > > > > > > > > > > > > I don't like criticizing you twice in one evening, but there are some > > > pretty serious problems with this code: > > > > > > * Filter is threaded, but you're not taking the required steps to make > > > mysql thread-safe: > > > > http://dev.mysql.com/doc/refman/5.0/en/threaded-clients.html > > > > > > > > > > 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. > > > > > > I don't think that's correct. I could be wrong, since I rarely use the > mysql C API (I'm actually not a big fan of MySQL in general), but it looks > to me like you at *least* need to call mysql_library_init() before you > create any threads. I think you also need to call mysql_thread_end() to > avoid memory leaks. You should check with the mysql list for further > confirmation, but I wouldn't trust this code to be thread safe as it is.
The last time I looked at this in detail (at least one major version of MySQL ago) things were handled a bit differently. Could be a portability problem. Better safe than sorry so the extra calls will go in. > > There's also a minor risk that "tp" will be changed in realmode before it's > copied in procmsg. You should pass that functions args by value only. > Either just pass fd as an arg, or allocate the memory in the realmode > function and pass the address to procmsg. Agreed. I wasn't too happy with that piece of code - a quick fix. > > Unrelated: I'm not confident that t->signature will have enough space if > the field values are much longer than the names from the template. It's > kind of hard to tell how that works, but it looks like a likely buffer > overflow to me. Thanks for spotting the bug. Should have used field values not names ;-( Also need to do some work to ensure that it doesn't generate excessively long lines. > > You should be looking for the first Received header, and examining its > contents. Stop there. Already fixed in the next version. > > > > Is there a definitive statement on the location/syntax of "AUTH:LOGIN" > anywhere? > > I can't see it in RFC2822/2821. > > > > > > I'm not sure. I think I used Courier's code as a reference. > > > I believe that it's possible to encapsulate the original, signed message in > a new MIME message, and add the signature as a text/plain part at the end. I'm reworking the code that signs multipart messages. A test confirmed that it did sign text/plain attachments which is very wrong. The encapsulation you suggest would, I imagine, be multipart/related but I'd want to be sure that all likely mail clients handle this correctly. BTW - they now want the company logo in the signature, I suppose I should be thankful they don't want it to sing the company song. > > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
