According to the RFC for the email date header (RFC 822 or newer RFC2822) a date header can have an optional "Day of the week in front" (e.g. "[ day "," ] date time").
However, code committed which is currently in v7.9.8 always expects it to be there
# modules/InboundEmail/InboundEmail.php:5270
// find if string has (UTC) in timezone
$pattern = "/\([\w-+\/]+\)/i";
$timezoneTextFound = preg_match($pattern, $header[0]->date);
$dateTimeFormat = 'D, d M Y H:i:s O *';
if($timezoneTextFound === false || $timezoneTextFound === 0) {
$dateTimeFormat = 'D, d M Y H:i:s O';
}
$dateTime = DateTime::createFromFormat(
$dateTimeFormat,
$header[0]->date
);
This means that if an email comes in with a date without the Day of the week (e.g. Date: 28 Dec 2017 10:58:42 -0500) that this code causes an exception to be thrown which is not handled.
You should be able to open up and view any RFC compliant email sent
Attempting to open a non-imported email which has a Date header without a day of the week shows an empty white screen
Correct the pattern matching on the Date header in _modules/InboundEmail/InboundEmail.php_
Unable to open all emails in order to import them into the CRM.
It appears this code was introduced fairly recently #3607 and is currently affecting all releases which would make it fairly high priority.
I don't think the current regular expression is doing anything at the moment - it won't match anything with a space in it, for example. If I'm not mistaken, all dates will contain spaces in them... you can play with it here.
So that also probably needs fixing; and then the issue with the day-of-week.
Note that PHP's DateTime object already has constants for this:
http://php.net/manual/en/class.datetime.php
includes
const string RFC822 = "D, d M y H:i:s O" ;
Funny, this also doesn't really take the all the variants of RFC822 into account... no provision there for dates without day-of-week either, nor for zone.
Maybe an easy approach would be to simply try for all the possible formats in succession, until one converts successfully.
@pgorod I was thinking the same thing with the timezone and tested it out with a regex tester as well. I was waiting to see the feedback on this before bringing that up.
For a quick solution to see if I was seeing the right bug I just did new \DateTime() rather than \DateTime::fromFormat(). But I don't really like that solution. I would probably make a loop around expected matching patterns or something. I did a quick google to see if this problem has been solved already and didn't immediately see anything, I would love to not re-invent the wheel.
I found a nice complete RFC822 Date regexp online:
https://regex101.com/r/hM5S77/1/
we can use this one.
@pgorod oh, I just wrote up a quick PR. What do you think of this: #4804
I think that looks fine! Maybe it's worth putting in a separate utility function in case it needs to be used elsewhere.
Thanks!
@pgorod I would agree; however, I would add that when a second use-case comes up I suppose. I also don't know enough about the arch of the software to decide where or how that should be implemented.
I got same error when i installed fresh beta 3 version of 7.10

@Mausino Did you try with my PR #4804
@isleshocky77 doesn't work for me, i did it and result is same as was on my screen. ( i flushed cache + repair/rebuild)
Most helpful comment
@pgorod I would agree; however, I would add that when a second use-case comes up I suppose. I also don't know enough about the arch of the software to decide where or how that should be implemented.