Page 1 of 1
After upgrade to 3.0.1.0 blank page on message view
Posted: 04 May 2016 11:46
by mauropavanello
hi to all,
After upgrade efa to 3.0.1.0 when i go into message i don't see the message body, i see a blank page.
this is what i see.
Is this correct or this is a bug?
any help?
thanks
Re: After upgrade to 3.0.1.0 blank page on message view
Posted: 05 May 2016 23:30
by shawniverson
Checking...
Re: After upgrade to 3.0.1.0 blank page on message view
Posted: 05 May 2016 23:39
by shawniverson
Unable to reproduce
Re: After upgrade to 3.0.1.0 blank page on message view
Posted: 06 May 2016 07:44
by DaN
just this mail or all mails?
Re: After upgrade to 3.0.1.0 blank page on message view
Posted: 06 May 2016 11:54
by mauropavanello
some mail not all.
To recovery i have install from scratch and it's ok.
thanks for reply.
Bye
Re: After upgrade to 3.0.1.0 blank page on message view
Posted: 06 May 2016 14:27
by DaN
..
Re: After upgrade to 3.0.1.0 blank page on message view
Posted: 31 May 2016 08:22
by wekal
Hi,
I can confirm, it is still in 3.0.1.1.
I found out, that in
viewmail.php
the
Code: Select all
$Mail_mimeDecode = new Mail_mimeDecode($file);
returns no 'body' element.
That is because in the mimeDecode Class the function _splitBodyHeader is searching for an empty line
Code: Select all
if (preg_match("/^(.*?)\r?\n\r?\n(.*)/s", $input, $match))
For some reason there has been a change in the quarantine file format. I found older Messages shown correct with viewmail.php. This files has usual line-breaks. Now these files are one-liners with null byte (\x00) as delimiter. Perhaps another format (mbox).
Anyone knows where to change back?
Regards,
Thomas
Re: After upgrade to 3.0.1.0 blank page on message view
Posted: 08 Jun 2016 13:38
by wekal
Hi,
now it's got weird. I've changed nothing in the configuration, but got good and bad messages from the same sender and the same recipient once readable and one time not. It's an e-commerce-process generated message, so it has the same Body-Text and only little changes in a XML attachment.
The detail.php parses both Messages fine, displays all Header Information correctly. They differ only in Message-ID and Times.
At the end of this Page, where the "Quarentine" section is, they differ:
Code: Select all
The working:
File Type Path
message message/rfc822 20160520/nonspam/4C50B121148.A09A9
message text/x-mail; charset=us-ascii 20160520/4C50B121148.A09A9/message
The non-working:
File Type Path
message message/rfc822 20160603/nonspam/520061201F6.A287E
520061201F6 application/octet-stream; charset=binary 20160603/520061201F6.A287E/520061201F6
I have put a var_dump($Mail_mimeDecode) in the viewmail.php witch gives me, for the working
Code: Select all
Mail_mimeDecode::__set_state(array(
'_input' => 'X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from xxxxxxx.otherone (xxxxx [1.2.3.4])
Blah bla... all fine
and the non-working
Code: Select all
Mail_mimeDecode::__set_state(array(
'_input' => 'C_ 34670 793 2 0 34670 0T1464945569 489566Acreate_time=1464945570Alog_ident=520061201F6Arewrite_context=remoteSxxxx@xxx.A log_client_name=xxxA!log_client_address=1.2.3.4Alog_client_
.... and so on ... than
' . "\0" . 'N4X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0N4X-Greylist: domain auto-white......
So it seems that something in the Mail-Scanner-Chain puts a bytecode in front of the message, which can not be parsed by Mail_mimeDecoder.
After a \0 comes the original Ascii, but with newlines replaced as
N4
Anyone here that can give me a hint?
Re: After upgrade to 3.0.1.0 blank page on message view
Posted: 08 Jun 2016 23:59
by shawniverson
This sounds like a perl bug, perhaps from a recently updated perl module. I am going to investigate.
https://github.com/E-F-A/v3/issues/288
Re: After upgrade to 3.0.1.0 blank page on message view
Posted: 21 Jun 2016 05:58
by wekal
I don't think so. I guess it is earlier in the mail flow.
Since 30th of May (perhaps I did an update this day) Mails are stored in a different way in Quarantine. The old mailsource-text-only one still works and a new binary format which doesn't.
Also the filename differs. The old working was stored as 'message' file, f.e.
/var/spool/MailScanner/quarantine/20160524/3900D12114A.A5ECC/message
The non-working are stored as filename with the message-id, f.e.
/var/spool/MailScanner/quarantine/20160530/7B697120C11.AB25F/7B697120C11
What step or process is responsible for saving this Mails in Quarantine?
It looks like the new binary Mail format puts some more Information in the head of the File:
C_ 24379386 704 1 0 24379386 0T^Q1464783318 868859A^Vcreate_time=1464783318A^Ulog_ident=E884312018EA^Vrewrite_context=remoteS^Yxxxmailfrom@domainxxxA!log_client_name=xxxremotesmtpservernamexxxA log_client_address=xxxremoteipxxxA^Ulog_client_port=44054A3log_message_origin=xxxremotename[ip]xxxA^_log_helo_name=xxxremotenamexxxA^Wlog_protocol_name=ESMTPA^]client_name=xxxremotenamexxxA%reverse_client_name=xxxremotenamexxxA^\client_address=xxxremoteipxxxxA^Qclient_port=44054A^[helo_name=xxxremotenamexxxA^Sprotocol_name=ESMTPA^Uclient_address_type=2A+dsn_orig_rcpt=rfc822;xxxlocalmail@domainxxxO^Vxxxlocalmail@domainxxxR^Vxxxlocalmail@domainxxxM^@N4X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0NDReceived: from .... Here comes the original Plaintext Mail, but with \0 as Line break.
And as subsequent fault Mime-Decode cannot parse this files, because it expected a Plaintext file with usual Line breaks.
Re: After upgrade to 3.0.1.0 blank page on message view
Posted: 21 Jun 2016 06:19
by wekal
Found it. It's in MailScanner.conf, this Setting
# When you quarantine an entire message, do you want to store it as
# raw mail queue files (so you can easily send them onto users) or
# as human-readable files (header then body in 1 file)?
Quarantine Whole Messages As Queue Files = no
There was yes for me, default is no.
Perhaps e.f.a. should work with both values
