Am .07.2014, 17:31 Uhr, schrieb Paul J Stevens :
On 21-07-14 17:11, Harald Leithner wrote:
btw, I looked at the use of find_boundary and its only used on message
reconstruction.
correct.
For performance reasons, I would suggest to move the boundary id
detection to the db insert message fu
On 21-07-14 17:11, Harald Leithner wrote:
> btw, I looked at the use of find_boundary and its only used on message
> reconstruction.
correct.
> For performance reasons, I would suggest to move the boundary id
> detection to the db insert message function and create a new boundary
> field in phy
btw, I looked at the use of find_boundary and its only used on message
reconstruction.
For performance reasons, I would suggest to move the boundary id detection
to the db insert message function and create a new boundary field in
phymessages table.
Maybe with a migration option for dbmai
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 message
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
l
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
