Am 03.09.2013 10:51, schrieb Thomas Raschbacher: > On 2013-09-03 10:25, Reindl Harald wrote: >> 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 >> >> > i am against sha checksums, since that would be quite a bit of extra cpu > load. > CRC should be fine to detect errors like this. > > see this link: > http://stackoverflow.com/questions/996843/when-is-crc-more-appropriate-to-use-than-md5-sha1
im fine with it too :-) the proposal was more a generic "how can we detect that we changed a message by deliver to the client from what we received by the MTA" to realize border-cases before users complain often enough with small differences the enduser does not recognize it because it is still displayed well i guess
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
