As usual, Tuesday is the day to update you on the progress of Google Summer of Code 2016 project - Mailhandler.

Last week both mentors and students had to fill Google Summer of Code midterm evaluation. The evaluation happened after 5 weeks of work and consisted of questions about the chosen organization, program, mentors (for students) and students (for mentors).

I am happy to announce that I have passed the midterm evaluation. Yay! I would like to give thanks to my mentors Primož and Miro. They were supporting me with reviews, ideas and suggestions in the past weeks. I hope we will continue the great cooperation in the second phase of the project as well. Here is the review I received from my mentors:

Miloš is very diligent and capable of self organising. There were no instances where we needed to remind him of his obligations or upcoming milestones. This goes equally for the technical as for the non-technical side of the project. He is always prepared to investigate the subject very carefully and find the best solutions to his knowledge. As a result his code never feels sloppy or produced just for the sake to make progress. He genuinely cares about the project. Being very goal oriented he sometimes neglects the discussion part slightly. This could be improved by requesting more feedback before jumping to implementation.

This week, GSoC students will continue the coding until the final evaluation which is scheduled for the second part of August 2016.

Back to the project updates. The last meeting with my mentors was very productive. We were talking about the weekly goal and had the broader discussion about the second phase of the project.

More specifically, we discussed the possibility to introduce the user context as a core feature of Inmail. I was writing about Inmail’s concept of plugins (analyzers, deliverers, handlers). Each analyzer has an option to analyze the mail message that is being processed and update the properties of a shared result object. This would allow collaboration between Inmail analyzers. To discuss different approaches, I created an issue on this topic. For now, the properties are updated on MailhandlerAnalyzerResult object.

Based on the discussion with mentors, we decided to split huge MailhandlerAnalyzer into several smaller analyzers. A pull request with the implementation can be followed on Github. The following analyzers were created (sorted by defaults execution order):

• PGP (Pretty Good Privacy) analyzer analyzes the PGP-signed email messages, verifies the signature, parses the mail body and sets the sender. Although there is specific BodyAnalyzer, for signed messages we have to parse the mail body to extract the signed text and PGP signature.

• Entity type analyzer - we have a concept of detecting an entity type and bundle information for the mail subject. For now, we only support: [node][{node_type}]. Later on, we will extend it to support comments entities too. The purpose of this analyzer is to recognize [{entity_type}][{bundle}] pattern, extracts the metadata information, do the validation and update the subject - without metadata.

• Sender analyzer uses a well-known feature of Mailhandler for Drupal 7. It extracts the mail address from From mail header field and finds the corresponding user. It is worth to mention that user is only set in case the user context is not already populated (by some other analyzer). This prevents us from changing the user context when it is set by PGPAnalyzer, for instance. Also, since this method is not entirely safe - From mail address can be faked by a malicious user, this analyzer is disabled by default.

• Footer analyzer detects the mail footer/signature in a mail body and updates footer and body properties. Two most used footer separators are supported. This analyzer was described in the previous blog post.

• Body analyzer works with the actual mail body. It has pretty limited functionality. It removes the white spaces before and after the body string using PHP’s standard method trim(). Also, in case processed body is not received as HTML, it replaces new lines \r\n with <br /> HTML tag. As the analyzer was implemented as a plugin, it can be easily extended.

MailhandlerNode is becoming much “cleaner”. Our algorithm has 3 steps:

1. Get MailhandlerAnalyzerResult which contains the result of all Mailhandler analyzers

2. Authenticate and authorize a user

3. Create a node.

The original complexity from one analyzer is now shared between 5 independent Inmail analyzers. This architectural simplification was made thanks to the great Drupal 8 plugin API. If you are more interested in exploring this topic, Drupalize.me published a great article about Drupal 8 plugin system.

Next week, I am going to work on extending the test coverage for the module. The plan is to create one kernel test per each created analyzer. The existing MailhandlerNodeTest will serve as a general test of all Mailhandler analyzers and MailhandlerNode handler. Also, I will provide additional test coverage of the Mailhandler’s user interface.