Re: RFE: checksum of original message in database
Paul J Stevens <[email protected]>
| Newsgroups | gmane.mail.imap.dbmail |
|---|---|
| Message-ID | <[email protected]> |
It's doable, and not very complex. I don't like doing database changes on 3.1 though. Good idea to include it in 3.2, I agree. On 21-07-14 13:18, Harald Leithner wrote: > Hi, > > I like this Idea and would go a step further, creating a checksum on an > incoming message and save it in the messages table. On reconstruction > check this checksum and don't push the mail to the customer if this > checksum does not match. Maybe retry the reconstruction several times > and log a message. > > This shouldn't be too hard to implement and would prevent user complaints. > > Paul, how long do you need and how much would it cost? > > I'm pretty sure Haralds company and I would pay for this feature. > > regards, > > Harald > > Am .07.2014, 16:32 Uhr, schrieb Reindl Harald (mobile) > <[email protected]>: > >> Hi Paul >> >> i would love a additional column in the message table containing the >> sha1 sum of the message before it get splitted in mime-parts or maybe >> better a own table with message-id and checksum and ignore that >> functionality if this table don't exist >> >> that would offer a option for dbmail-util check reconstruction of >> current stored messages and by ignore old ones not having that value >> no compatibility break >> >> maybe that verification could go in a small new binary outside >> dbmail-util with a few options like limit the number of verified >> messages and specify a date range and produce a csv like output with >> userid, mailboxid, date and subject and last but not least integrity >> check of a specific message id >> >> that would greatly improve debugging / verification and in case of a >> complete raw message by a client that could also optionally calculated >> / verified and mismatch logged in the maillog to get some valuable >> Information in case of unpredictable bugs like the current >> reconstruction under load >> >> surely it needs resources on the server, hence the idea of a separate >> table to enable that behaviour but at the end of the day it gives us >> the opportunity to have an insight in overall integrity and early >> detection of regressions, their impact, easy confirmation of bugfixes >> by knowing the hash of the original message, and messages known to be >> broken before the proposed fix >> >> >> >> -- >> >> 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 >> [email protected] >> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail > > -- ________________________________________________________________ Paul J Stevens pjstevns @ gmail, twitter, github, linkedin www.nfg.nl/[email protected]/+31.85.877.99.97 _______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail