Hi,
I've looked into the issue a bit more, as I got another email this
morning where the attachments were incorrectly sorted. I've been unable
to pinpoint the reason, though.
I get the mail with two attachments and one plaintext part. If I take a
look at the database, I see the following entries in the attachment SQL
table:
Article Filename Content Type Content
-----------------------------------------------------------------------------------------
12641 warp8.pdb text/plain; charset="iso-8859-15" [BLOB - 1,8 KB]
12641 file-1 application/octet-stream; name="warp8 Logo.pdb" [BLOB - 39,4 KB]
12641 warp8 Logo.pdb application/octet-stream; name="warp8.pdb" [BLOB - 27,2 KB]
As you can see, the attachments were sorted in in a completely wrong
order. Just an hour later I extracted the email from
~otrs/var/INBOX.Backup.2004-05, changed the sender to my email address
and piped it into the system again (it doesn't matter whether via "cat
email | procmail" or "cat email | bin/PostMaster.pl"). And now the email
is displayed correctly:
Article Filename Content Type Content
-----------------------------------------------------------------------------------------
12646 warp8 Logo.pdb application/octet-stream; name="warp8 Logo.pdb" [BLOB - 39,4 KB]
12646 warp8.pdb application/octet-stream; name="warp8.pdb" [BLOB - 27,2 KB]
12646 file-1 text/plain; charset="iso-8859-15" [BLOB - 908 Bytes]
What puzzles me is that the iso-8859-15 part has actually been bigger
the first time the mail was processed, somewhere it seems to have lost
about 900 bytes?
Apart that the attachments are now stored correctly, the only other
significant change is the create_by column. For the "real" email this
was set to "2", whereas the resend email had this column set to "1". I
couldn't find the part in the source where this is set and I am not sure
what 1 and 2 mean. Taking a closer look at the database it seems that 2
is used for outgoing attachments and 1 for incoming? - which doesn't
really make sense as the first mail has not been an outgoing one.
Does anybody have any idea what might be going wrong here?
--
Daniel Seifert