After upgrade to 3.0.1.0 blank page on message view

[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

[shawniverson]

Checking...

[shawniverson]

Unable to reproduce

[DaN]

just this mail or all mails?

[mauropavanello]

some mail not all.
To recovery i have install from scratch and it's ok.
thanks for reply.

Bye

[DaN]

..

[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

[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?

[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

[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.

[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