Content-Type weirdness with NotifyWithAttachment

When an attachment is sent from RT, some of the receivers
a) get the attachment properly (e.g. as a clickable button in Evolution)
and the e-mail they get has
Content-Type: multipart/mixed; boundary="=-JavorBxnEQqN23h7VQxc"
(with variable boundary, of course)

b) Others get the whole mime thing inline and e-mail has
Content-Type: text/plain; CHARSET=US-ASCII

For example, lynoure@otaverkko.fi gets broken ones, but
lynoure@isis.otaverkko.fi doesn’t, and I read both of the mails on the
same Evolution mail client.

Has anybody had this kind of behaviour? I can supply full mail headers
for both cases if somebody thinks it would help.

Lynoure Rajamäki
lynoure@otaverkko.fi

My problem is still unsolved, but I noticed RT with NotifyWithAttachment
sets the boundary in multipart/mixed messages to be form

------------=_1039689841-20574-4

when having
Content-Type: multipart/mixed; boundary="=-1039689841-20574-4
according to RTF 1521 it should have two hyphens and no more, e.g.

–=_1039689841-20574-4

Could somebody point out where the boundary is set so I can get rid of
the extra hyphens? Or would this question be better asked from rt-devel?

The non-working multipart messages always show the lots of hyphens in
front of a numerical boundary while the working ones show only the two
in front of an alphanumerical boundary. I think some MTAs replace the
non-standard boundary marks.

Lynoure Rajamäki
lynoure@otaverkko.fi

Lynoure Rajam?ki wrote:

My problem is still unsolved, but I noticed RT with NotifyWithAttachment
sets the boundary in multipart/mixed messages to be form

------------=_1039689841-20574-4

when having
Content-Type: multipart/mixed; boundary="=-1039689841-20574-4
according to RTF 1521 it should have two hyphens and no more, e.g.

–=_1039689841-20574-4

Good catch…

Could somebody point out where the boundary is set so I can get rid of
the extra hyphens? Or would this question be better asked from rt-devel?

This is set in MIME::Entity, in particular the “make_boundary” sub.
This generates a boundary with ten leading dashes (which agrees with
the twelve dashes you see in your boundary.) However these ten dashes
are absent in the Content-Type header. Why? I don’t know. But that
should at least give you a starting point. :slight_smile: Good luck…

Phil Homewood, Systems Janitor, www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances

This is set in MIME::Entity, in particular the “make_boundary” sub.
This generates a boundary with ten leading dashes (which agrees with
the twelve dashes you see in your boundary.) However these ten dashes
are absent in the Content-Type header. Why? I don’t know. But that
should at least give you a starting point. :slight_smile: Good luck…

That was my mistake, it seemed to be that way in the Content-Type as
well. Confusing. Anyway, I got rid of the extra hyphens.But it seems
that the content type and encoding of the first part
{$Transaction->Content()} is left unset and it seems to me (poor perl
newbie) that there is no way to set it afterwards. I have found out a
way to add {$Transaction->Content()} as a plain text attachment but then
there will be an extra empty attachment above that and alas, things are
broken that away. (So a way of removing an attachment would be good
too.)

Postfix and exim seem to fix the messages not including
Content-Transer-Encoding or Content-Type for the first message, qmail
and sendmail instead seem to assume it’s no multipart.

This is such a weird problem that I almost feel embarrashed about it
(and my non-existent perl skills) but I have had the same attachment
behaviour on two different RT installations now.

Lynoure Rajamäki
lynoure@otaverkko.fi