Line endings - how are they touched in any way due split the mime parts? they should not change in any direction nor fixed for messages having the wrong ones before touch dbmail - my attention goes here more to signed messages than specific clients
<Nitpicking Mode> for me reconstruction is anything which would lead to whatever difference in the message the client receives to the one received by the MTA </Nitpicking Mode> What about store the SHA checksum of messages before they are splitted and inserted and bail out in the moment POP3 or IMAP are deliver a non matching one to the client - the SHA1 at receive should not matter in performance and the verify and bail per config option the idea is that we may find border cases we never imagine while the client may not always display things wrong but dbmail could bail itself also in cases nobody minds -------- Ursprüngliche Nachricht -------- Von: Paul J Stevens <p...@nfg.nl> Gesendet: Tue Sep 03 09:34:02 MESZ 2013 An: DBMail mailinglist <dbmail@dbmail.org> Betreff: Re: [Dbmail] DBMail 3.1.4 released On 09/03/2013 12:13 AM, Reindl Harald wrote: > so we know two important things > > * for whatever reason re-construction has still a problem Not everything is about re-construction! This is about the wire-protocol: CRLF encoding. Outlook really should treat LF as a line-ending, but DBMail really must send CRLF Let me repeat: there is no corruption, and no re-construction issue here. It's about encoding the data before sending it to the client. > * split and store of messages was and is still fine There may be some issues with message/digest. The imaptest is still failing there. Apart from that: no known issues. -- Reindl Harald (mobile) the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / CISO / Software-Development +43 (676) 40 221 40 http://www.thelounge.net _______________________________________________ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
