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: dbmail-bounces dbmail.org [mailto:dbmail-bouncesdbmail.org] 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: dbmail-bouncesdbmail.org [mailto:dbmail-bouncesdbmail.org] 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: dbmail-bouncesdbmail.org
[mailto:dbmail-bouncesdbmail.org] 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: blahfoo
> To: blahbar
> Subject: asdf
>
> Ipsum lorem ad nauseum.
> --------------------------
>
> will be split like:
>
> ----<cut>----
> From: blahfoo
> To: blahbar
> Subject: asdf
> ----<cut>----
> Ipsum lorem ad nauseum.
> ----<cut>----
>
>
> A multipart message:
>
> --------------------------
> From: blahfoo
> To: blahbar
> 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: blahfoo
> To: blahbar
> 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
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail
|
