Paul, In the changelog you have the change details for day 2007-12-17 double.
Can I update now using the last trunk or now yet? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jorge Bastos Sent: terça-feira, 18 de Dezembro de 2007 10:31 To: 'DBMail mailinglist' Subject: RE: [Dbmail] Re: DBMail 2.3.0 released Ok i'll Paul. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul J Stevens Sent: terça-feira, 18 de Dezembro de 2007 9:50 To: DBMail mailinglist Subject: Re: [Dbmail] Re: DBMail 2.3.0 released Jorge Bastos wrote: > Perfect then! > > Paul can i upgrade my server to 2.3x now? Just insert the database changes > and compile the 2.3x code. No! There is a bug in the delivery that will break delivery on mysql. Wait for 2.3.1 later today. > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Paul J Stevens > Sent: terça-feira, 18 de Dezembro de 2007 8:41 > To: DBMail mailinglist > Subject: Re: [Dbmail] Re: DBMail 2.3.0 released > > Michael Monnerie wrote: >> On Montag, 17. Dezember 2007 Daniel Urstöger wrote: >>> but all with the same file size? I wonder if the guys are >>> implementing some kind >>> of checksum too, then it won´t matter at all, I assume... >> There was some discussion about that in summer, and yes, there are of >> course checksums. By the time it was found that SHA256 would be >> sufficient IIRC, but I don't know what Paul has used now. >> >> So there shouldn't be any realistic collision possible. > > I'm using sha1, not sha256. > > And I'm hashing MIME-payload and MIME-headers, not full mime-parts. That > means > that even if the same file is sent using different names (myfile.pdf and > yourfile.pdf) that file is stored only once since the actual payload will > render > the same hash. > > > A very simply message: > > -------------------------- > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: asdf > > Ipsum lorem ad nauseum. > -------------------------- > > will be split like: > > ----<cut>---- > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: asdf > ----<cut>---- > Ipsum lorem ad nauseum. > ----<cut>---- > > > A multipart message: > > -------------------------- > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: sadf > MIME-Version: 1.0 > Content-type: multipart/mixed; boundary=boundary > > This message will not be seen by the user > > --boundary > Content-type: text/html > Content-disposition: inline > > <html><head></head><body>Message</body></html> > > --boundary > Content-type: text/plain; charset=us-ascii; name=testfile > Content-transfer-encoding: base64 > > IyEvYmluL2Jhc2gNCg0KY2xlYXINCmVjaG8gIi4tLS0tLS0tLS0tLS0tLS0t > IyEvYmluL2Jhc2gNCg0KY2xlYXINCmVjaG8gIi4tLS0tLS0tLS0tLS0tLS0t > IyEvYmluL2Jhc2gNCg0KY2xlYXINCmVjaG8gIi4tLS0tLS0tLS0tLS0tLS0t > --boundary-- > -------------------------- > > will be cut along the following lines: > > ----<cut>---- > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: sadf > MIME-Version: 1.0 > Content-type: multipart/mixed; boundary=boundary > > ----<cut>---- > This message will not be seen by the user > ----<cut>---- > Content-type: text/html > Content-disposition: inline > ----<cut>---- > <html><head></head><body>Message</body></html> > ----<cut>---- > Content-type: text/plain; charset=us-ascii; name=testfile > Content-transfer-encoding: base64 > > ----<cut>---- > IyEvYmluL2Jhc2gNCg0KY2xlYXINCmVjaG8gIi4tLS0tLS0tLS0tLS0tLS0t > IyEvYmluL2Jhc2gNCg0KY2xlYXINCmVjaG8gIi4tLS0tLS0tLS0tLS0tLS0t > IyEvYmluL2Jhc2gNCg0KY2xlYXINCmVjaG8gIi4tLS0tLS0tLS0tLS0tLS0t > ----<cut>---- > > Notice how the '--boundary' strings are missing after splitting. Each part > between the ---<cut>--- lines will be stored as a separate mimepart in the > dbmail_mimeparts table using it's sha1 hash as it's primary key. Message > parts > are linked together using the partlists table. Using this partlists table, > message are reconstructed during retrieval adding back the boundary strings > as > indicated by the boundary field in the Content-type header. > > The same pattern applies to nested mime constructs as well, such as > multipart/mixed messages that contain message/rfc822 mimeparts that contain > multipart/mixed messages. We simply recurse into the nested structure. Well > not > so simple, but it works great. > -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
