I have a strange problem with the report Mail sent by Veritas Backup
Exec which is an UTF-8 Mail with the report attached as HTML File
(Base64 encoded).
I used to run eGroupware 1.2.100 (Gentoo Linux Package) together with
Courier. I recently migrated the IMAP Server to Cyrus 2.2.12 (worked
wonderfully with imapsync). Since then the reports sent by Veritas
Backup Exec are not displayed correctly anymore. This concerns the old
reports that were already delivered when I did the migration as well as
the new one coming in every day. In Courier the report displayed as a
"correct" mail with one attachement of the type
application/octet-stream. When clicking on the attachment one could
open it selecting a browser as application. With cyrus the text part of
the mail is also displayed correctly but the attachement is also shown
as being part of the text part of the mail (with a lot of strange
symbols). The whole mail is also shown to be one attachment of the type
text/plain. If I connect the the Cyrus-Server with Sylpheed or
Thunderbird the mail is displayed as it was with courier. That’s why I
believe it’s a problem with eGW…
(Server: “DC”) (Auftrag: “Datensicherung ohne Lakos”) Der Auf=
trag wurde erfolgreich abgeschlossen. Es traten jedoch die folgenden Bedi=
ngungen auf:
Ein f=C3=BCr diesen Auftrag erforderlicher Schnappschu=C3=9Fvorgang wurde=
nicht erfolgreich durchgef=C3=BChrt. Weitere Informationen finden Sie im=
Auftragsprotokoll und in der Windows-Ereignisanzeige.
and then comes the attachment. I’m not sure but I could imagine that somehow
the utf-8 charset is causing eGW troubles to recognize the beginning of the
attachment.
If I copy the mail file out of the cyrus spool directory to a server
running courier and eGW, the mail is displayed fine.
Does someone have an idea how I can solve this problem?
Best regards.
Jean-Pierre
–
HILOTEC Engineering + Consulting AG
Energietechnik und Datensysteme
Tel: +41 34 402 74 00 - http://www.hilotec.com/
I have a strange problem with the report Mail sent by Veritas Backup
Exec which is an UTF-8 Mail with the report attached as HTML File
(Base64 encoded).
Can you please forward me such a message as attachment?
I have a strange problem with the report Mail sent by Veritas Backup
Exec which is an UTF-8 Mail with the report attached as HTML File
(Base64 encoded).
Can you please forward me such a message as attachment?
@ Lars:
I don’t know if you already had time to take a look into my changes to
felamimail but this kind of problems looks quite familiar to me.
There are mails out there that the IMAP extension of PHP is unable to
analyze, even though they appear to be rfc conformant.
This is the reason I took MimeDecode of PEAR to build up the message
structure and for tearing out the different parts.
@Jean-Pierre:
Would you mind to send me such a mail too (forwarded as an attachment, like
done by felaimail) ? Thank you.
Sven
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share
I have a strange problem with the report Mail sent by Veritas Backup
Exec which is an UTF-8 Mail with the report attached as HTML File
(Base64 encoded).
…
Thanks for submitting the original mail. The only odd thing I can see is the
malformed “Content type” header for the attachment. It is missing the ";"
after the type proper and its parameter “name” is not a standard part of
this header. If it is necessary here it could be made a comment by enclosing
it in parentheses ().
HTH
Sven
Best regards.
Jean-Pierre
–
HILOTEC Engineering + Consulting AG
Energietechnik und Datensysteme
Tel: +41 34 402 74 00 - http://www.hilotec.com/
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share
Thanks for submitting the original mail. The only odd thing I can see
is the malformed “Content type” header for the attachment. It is
missing the “;” after the type proper and its parameter “name” is not
a standard part of this header. If it is necessary here it could be
made a comment by enclosing it in parentheses ().
Thank you for looking into that issue.
Indeed. If I remove the name attribute and and a ; after the
Content-Type then it’s displayed right the way it should.
The one thing I still don’t understand is why it is displayed correctly
(with the non-standard name-header) when the message is stored on a
courier imap server but not when it’s stored on a cyrus imap server.
Is the message parsing done with another technique when cyrus is
selected as imap server type?
Regards.
Jean-Pierre
–
HILOTEC Engineering + Consulting AG
Energietechnik und Datensysteme
Tel: +41 34 402 74 00 - http://www.hilotec.com/
I must admit, I don’t know the intimate details, but in this case I think
the cyrus is a bit more picky about rfc compliance. FeLaMiMail as of 1.2
uses the PHP-IMAP extension to retrieve message parts from IMAP servers
which itself cannot handle everything that comes along ones way.
In any case: when it is seen by FeLaMiMail, it’s too late.
Thanks for submitting the original mail. The only odd thing I can see
is the malformed “Content type” header for the attachment. It is
missing the “;” after the type proper and its parameter “name” is not
a standard part of this header. If it is necessary here it could be
made a comment by enclosing it in parentheses ().
Thank you for looking into that issue.
Indeed. If I remove the name attribute and and a ; after the
Content-Type then it’s displayed right the way it should.
The one thing I still don’t understand is why it is displayed correctly
(with the non-standard name-header) when the message is stored on a
courier imap server but not when it’s stored on a cyrus imap server.
Is the message parsing done with another technique when cyrus is
selected as imap server type?
Regards.
Jean-Pierre
–
HILOTEC Engineering + Consulting AG
Energietechnik und Datensysteme
Tel: +41 34 402 74 00 - http://www.hilotec.com/
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share