Hello!
We are using RT-3.0.7 with perl 5.8.2 on FreeBSD.
If I submit the following e-mail to RT, it can not be delivered with the
following error in maillog:
Dec 11 15:26:11 rtfm postfix/local[49606]: 7AB9FB531F: to=test@rtfm.demos.su,
relay=local, delay=1, status=deferred (temporary failure. Command output: RT ser
ver error. The RT server which handled your email did not behave as expected. I
t said:
System error
error: </
td> |
write-open /tmp/loido8WCkq/ : Is a directory at /usr/local/lib/
perl5/site_perl/5.8.2/MIME/Body.pm line 414.
|
context: | <font face="Verdana, Arial, He
This message can be found at:
http://mitya.pp.ru/tmp/rt3.msg
|
I can confirm that this crashes RT here too.On Thu, Dec 11, 2003 at 03:34:32PM +0300, Dmitry Sivachenko wrote:
Hello!
We are using RT-3.0.7 with perl 5.8.2 on FreeBSD.
If I submit the following e-mail to RT, it can not be delivered with the
following error in maillog:
Dec 11 15:26:11 rtfm postfix/local[49606]: 7AB9FB531F: to=test@rtfm.demos.su,
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
Hello!
We are using RT-3.0.7 with perl 5.8.2 on FreeBSD.
If I submit the following e-mail to RT, it can not be delivered with the
following error in maillog:
The problem is that this message names its parts " ". Which…MIME parser
has trouble writing to disk.
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
Hello!
We are using RT-3.0.7 with perl 5.8.2 on FreeBSD.
If I submit the following e-mail to RT, it can not be delivered with the
following error in maillog:
The problem is that this message names its parts " ". Which…MIME parser
has trouble writing to disk.
Well, RT should have a workaround for that.
Rt should not crash on any input, regardless how bad it is.
The problem is that this message names its parts " ". Which…MIME parser
has trouble writing to disk.
Well, RT should have a workaround for that.
Rt should not crash on any input, regardless how bad it is.
I agree entirely. I was just giving you a status update when I
determined what was causing the issue.
Anyway, it’s fixed as of change 382. MIME::Parser has an option that
does what I thought it did all along – not trust those attachment
names.
-jesse
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.