E. Choroba

I was assigned DateTime::Format::Mail for September in the Pull Request Club. There was one open issue in its GitHub repository, so I hoped solving it would be my pull request for the month.

The reporter complained the module fails to parse the following e-mail header:

Date: Wed, 10 Jul 2019 11:20:02 +0200 (CEST)

I cloned the repository and briefly examined it. It’s based on Dist::Zilla, but running

prove -l

worked for me without the need to call dzil. I noticed a test named “sample.t” that took the largest part of the testing time and read its source. It read strings from a file and tried to parse each of them. I added the problematic string into the file and reran the test—only to find it still passed.

I replied to the bug report that I couldn’t reproduce the problem. Within few minutes, the reporter sent me the exact line that didn’t work for him:

perl -MDateTime::Format::Mail -e '
    DateTime::Format::Mail->new->strict->parse_datetime("Wed, 10 Jul 2019 11:20:02 +0200 (CEST)")'

The important difference to what the test did was the ->strict method. It switches the parser object into a strict mode that is less tolerant than the loose mode used in the test. In this case, it’s the parenthesised time zone name that’s invalid: comments are forbidden in dates by the current standard.

As pointed out by PALI, one should use the loose method to parse incoming e-mail headers, so they don’t reject messages sent from old systems not conforming to the latest standards. When creating an e-mail header, though, you should switch to the strict mode, so you produce the header according the up-to-date specification.

For details, see RFC-822 and RFC-2822.

DateTime::Format::Mail is a small module. I didn’t find anything else to work on, and as September was already over, I decided to skip the month. I don’t feel bad about it, though: I helped the module’s user and solved an open issue.