I would hope average user has their clock set reasonably correct. Therefore, Eudora might wish to declare any date more than 2 days in future invalid and go by last time in received records.
Most servers are pretty close.
Individual users who have reverted to 1956 need to reset. Suggesting 2 days in future because it is not uncommon for messages to be one day in future based on local time of sender in another time zone. While CompuServe doesn't provide the ofset from UCT and has month before day and is missing a comma, I can sure read it. I would hope a program could as well. That's too far away from standard.