Truncated email from notify on create

RT Users
1

Hi,

I’m seeing a very odd issue with a particular set of emails from one particular requestor, I have an example email and the problem is 100% repeatable. When the email is loaded for the first time into RT the ticket is created ok, and autoreply is sent to the requestor ok, but when it gets to notifying AdminCCs it sends a partial email and does not log the transaction. That is the AdminCCs get an email with the correct headers but the email body is only a couple of lines, missing out the majority of the email, and when you look in the RT web interface you see the ticket, the autoreply transaction but there is no transaction for the BCC email to the AdminCCs.

Is this something that anyone else has seen? Is anyone intereseted and able to help debug this?

The RT server is:

FreeBSD 10.3-RELEASE-p18

Apache 2.4.25

Perl 5.24.1

ModPerl 2.0.10

The email throwing the issue has a plain text body. Any subsequent comments to the ticket do send emails correctly to the AdminCC watchers. I’ve configure a log in RT_SiteConfig.pm and don’t see anything weird nor in the Apache error logs, so far as I can tell,

thanks for any help! Andy.

2

No one any ideas on this?? :frowning:

thanks, Andy.

3

Pretty sure it’s same problem https://forum.bestpractical.com/t/problem-with-utf-8-in-subject

4

Hi Albert,

unfortunately not. Having downgraded the DBD-MySQL module, here is version shown from perl:

DBD::mysql 4.041_02

I’m still seeing the same issue unfortunately

still really no clues as to whats going on :frowning:

if anyone has any other ideas please let me know!

thanks, Andy.

5

Le 22/06/2017 à 18:09:06+0000, a.smith@ldex.co.uk a écrit

unfortunately not. Having downgraded the DBD-MySQL module, here is version
shown from perl:

DBD::mysql 4.041_02

No. The right version is 4.0.41. You can check here on the CPAN

http://cpansearch.perl.org/src/MICHIELB/DBD-mysql-4.042/Changes

the modification about utf-8 begin at 4.041_1

So the « right » version is 4.0.41.

Regards.

6

Ah ok, I understood the change was introduced in 4.0.42. I´ll test 4.041 on Monday,

thanks, Andy.

7

Hi Albert, all,

I can confirm that unfortunately this problem still exists with DBD-mysql-4.041,

any other suggestions gratefully welcomed…

thanks, Andy.

8

Ok, update on this. The content of the original email request is plain text and contains this:

Dear customer,

Due to some maintenance works to improve the quality of the XXXXX Network, the services with the following references
.
1-300027057, 1-300027058

If I remove the “.” on the line before the refernce numbers the correct info is sent to the queue watchers. When the “.” is left the content is truncated up to, but not including, the “.”
So its like something is interpreting it as an end of file or something. Anyone any clues?

thanks, Andy.

9

If I remove the “.” on the line before the refernce numbers the correct info
is sent to the queue watchers. When the “.” is left the content is truncated
up to, but not including, the “.” So its like something is interpreting it
as an end of file or something. Anyone any clues?

A ‘.’ on a line by itself can be treated by some MTAs as an end-of-file
indication (sendmail is one such MTA).

For sendmail this behaviour can be suppressed by invoking with the ‘-i’
option, or setting “IgnoreDots” in sendmail’s config file.

If you’re using an MTA other than sendmail, perhaps it behaves similarly, but
you’ll have to research yourself if/how you can make it behave differently…

Duncan

10

Yep, spot on Duncan! I’m using Exim, and the same -i option applies.

thanks a lot! Andy.

11

The period on the line by itself is defined in RFC 2821 as an end-of-message indicator. The email sender is supposed to double it before sending while the email receiver knows to strip the extra off on reading. This has been standard email protocol for years. You need to tell the sender of this email they are sending non-compliant email, causing you to loose part of their message.

/jeff