Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subject line (data) not being respected #4780

Closed
rcubetrac opened this issue Mar 2, 2015 · 19 comments

Comments

Projects
None yet
1 participant
@rcubetrac
Copy link

commented Mar 2, 2015

Reported by citechnical on 2 Mar 2015 05:03 UTC as Trac ticket #1490295

I installed the latest version 1.1.0 on my company CentOS 7 server and I'm sending and receiving mail now. I am, however not able to set the Subject: on outgoing mail. My wife sent me a mail and it came through (No Subject) and I tested similarly to another email and that mail came through (No Subject). We are typing in the Subject textbox but after the mail goes, the subject is lost.

I did not find this issue listed on this Trac site nor did I find anything via Google.

Thanks,

David L. Whitehurst

Migrated-From: http://trac.roundcube.net/ticket/1490295

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 2, 2015

Comment by @alecpl on 2 Mar 2015 08:30 UTC

So Subject header does not exist in the message source? Does it exist in the message saved in Sent folder? Does it exist in the message saved as draft? Enable smtp_debug/imap_debug and check in the log if the header is sent to the server(s).

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 2, 2015

Milestone changed by @alecpl on 2 Mar 2015 08:30 UTC

later => 1.1.1

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 2, 2015

Comment by citechnical on 2 Mar 2015 19:06 UTC

Logs from a test to dlwhitehurst@me.com

[14:00:47 -0500](02-Mar-2015): <6fl0m3ib> Send: MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;^M
 format=flowed^M
Content-Transfer-Encoding: 7bit^M
Date: Mon, 02 Mar 2015 14:00:47 -0500^M
Subject: ^M
@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 2, 2015

Comment by @alecpl on 2 Mar 2015 19:23 UTC

Ok, find program/steps/sendmail.inc file and put

console($_POST);

on start. This will log the POST data to logs/console file. Additionally debug POST request in the browser. Let's see where it is lost.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 4, 2015

Comment by fpiraz on 4 Mar 2015 01:29 UTC

The issue occurs next to the line 513 of this program/steps/sendmail.inc.

// encoding subject header with mb_encode provides better results with asian characters
if (function_exists('mb_encode_mimeheader')) {
    mb_internal_encoding($message_charset);
    $headers[= mb_encode_mimeheader($headers['Subject']('Subject']),
        $message_charset, 'Q', "\r\n", 8);
    mb_internal_encoding(RCUBE_CHARSET);
}

The mb_internal_encoding function is setting the subject as null.

Here is your log snap from console($headers):

20:21:11 -0500: <73tvit64> array (
'Date' => 'Tue, 03 Mar 2015 20:21:11 -0500',
'From' => 'test@test.com',
'To' => 'A TEST TEST@TEST.COM',
'Subject' => NULL, <--- Here is the error
'Message-ID' => '00987a2c2f2fdf33d21f2d92c6aad434@viamaple.com',
'X-Sender' => 'test@test.com',
'User-Agent' => 'Roundcube Webmail/1.1.0',
)

Just tested with iconv_mime_encode and I've got subject as false:

20:19:31 -0500: <73tvit64> array (
'Date' => 'Tue, 03 Mar 2015 20:19:31 -0500',
'From' => ''test@test.com',
'To' => 'A TEST TEST@TEST.COM',
'Subject' => false,
'Message-ID' => '0641fb1f8e5fed5887455396d81a6723@viamaple.com',
'X-Sender' => 'test@test.com',
'User-Agent' => 'Roundcube Webmail/1.1.0',
)

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 4, 2015

Comment by fpiraz on 4 Mar 2015 01:32 UTC

I've just commented the code on the comment:4 on the program/steps/sendmail.inc file and I have my subjects back. I'm using this as a workaround by now.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 4, 2015

Comment by citechnical on 4 Mar 2015 05:09 UTC

This worked for me too. I tried setting mb_encoding_internal to UTF-8 and then the subject line to UTF-8 as well. That did not work. If I can solve this I'll post a solution. For now, I'm commented.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 4, 2015

Comment by Microkeeper on 4 Mar 2015 05:11 UTC

Hi, I was having the same issue.
Commenting out that code in the sendmail.inc resolved the problem.
Just thought I would add we are using PHP version 5.3.27

I noticed roundcube drop support for PHP < 5.3.7

Upgrading PHP is probably a good idea though.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 4, 2015

Comment by citechnical on 4 Mar 2015 05:17 UTC

I'm using PHP 5.4.16. I'll be waiting to see what the team developers do with this. I would love to fix it myself. I'm a Java professional. I know enough about PHP to be dangerous.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 4, 2015

Comment by @alecpl on 4 Mar 2015 06:55 UTC

So, you have some "strange" characters in the subject? Does it work with ASCII-only? Provide an example.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 4, 2015

Comment by Microkeeper on 4 Mar 2015 12:34 UTC

I've tried many examples simple text eg "hello" to more complicated eg "New ticket #1234-asdf"
They call get converted to null (No Subject)

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 4, 2015

Comment by @alecpl on 4 Mar 2015 12:45 UTC

Strange, do you have php-mbstring extension installed?

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 4, 2015

Comment by citechnical on 4 Mar 2015 14:36 UTC

I just did:

yum install php-mbstring to my server and it was NOT installed. I tried again with subject: "This One Should Work" and it did NOT work.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 4, 2015

Comment by @alecpl on 4 Mar 2015 14:41 UTC

Did you restart apache/php? We would fix this anyway, but would be good to know if it's Patchwork issue or PHP issue. We don't use Patchwork's mbstring implementation since f070da7.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 4, 2015

Comment by citechnical on 4 Mar 2015 14:58 UTC

Ok. Adding php-mbstring and restarting HTTPD corrected this problem. Thanks Alec for all your help. At least we know now it's not the RoundCube software (PHP).

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 4, 2015

Comment by @alecpl on 4 Mar 2015 17:32 UTC

So, the commit I provided already fixes the issue, but I also decided to remove the mb_encode_mimeheader() use in f02fe3c.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 4, 2015

Status changed by @alecpl on 4 Mar 2015 17:32 UTC

new => closed

@rcubetrac rcubetrac closed this Mar 4, 2015

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 5, 2015

Comment by @thomascube on 5 Mar 2015 07:57 UTC

The comment in the source said "mb_encode provides better results with asian characters". I guess there was a reason we added it in the first place. Did you verify that removing it isn't a regression with asian characters?

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 5, 2015

Comment by @alecpl on 5 Mar 2015 08:17 UTC

Yes. This was added almost on the beginning and commit says nothing more about that change. It probably creates better results only for some charsets and when $message_charset is not UTF-8. So, not a common case. I tested some Japanese characters and got the same result (using utf) with and without this code.

@rcubetrac rcubetrac added this to the 1.1.1 milestone Mar 20, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.