Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Aug 17 2016
Aug 17

It’s been more than 13 warm weeks since I’ve started to work on my Google Summer of Code 2016 - Mailhandler project. During the past few weeks, I finished the coding and worked on latest improvements related to documentation.

In the past week, the project documentation has been updated which was the last step before merging Github repository and Sandbox project into Mailhandler. Drupal 8 release section was updated and it summarizes the features of D8 version. If you are wondering where you can use the code I developed this summer, feel free to read about a real-life Mailhandler use-cases.

This week, I am doing the latest cleanups and preparing the project for the final evaluation. It is the second evaluation after I submitted the midterm evaluation. In case you missed the previous posts from Google Summer of Code series, I am providing the project retrospect below.
 

Project Retrospect

In early February, in an ordinary conversation, a friend of mine told me about this year’s Google Summer of Code program. I got interested in it since I took part in GHOP (The Google Highly Open Participation Contest; This program was replaced with Google Code-In) during high-school.

In March, I’ve found out that Drupal will be one of the participating organizations and since I did a Drupal internship last year, this seemed to be a perfect opportunity to continue open-source contribution.

Among many interesting project ideas, I decided for “Port Mailhandler to Drupal 8”. Miro Dietiker proposed the project and during the proposal discussions, Primoz Hmeljak joined the mentoring team too.

The great news came in April. I was one of the 11 students chosen to contribute Drupal this summer! First Yay moment!

The project progress could have been followed on this blog, so I’m will not go into great details about this.

3 months of work passed quickly and at this point, I can confirm that I learned a ton of new things. I improved not only my coding skills but communication and project management skills too.

In my opinion, we reached all the goals we put on the paper in April. All the features defined in the proposal were developed, tested and documented.

Google Summer of Code is a great program and I would sincerely recommend all the students to consider participating in it.

Future plans

The future plans about the module are related to its maintenance. Inmail is still under development and it seems it will be ready for an alpha release very soon. I created an issue about nice-to-have features of Mailhandler. This issue could serve as a place for Drupal community to discuss the possible ways of the future Mailhandler development.


Thank you note

Last but not least, I would like to give huge thanks to my mentors (Miro Dietiker and Primoz Hmeljak) for being so supportive, helpful and flexible during this summer. Their mentoring helped me in many ways - from the proposal re-definition in April/May, endless code iterations, discussions of different ideas to blog post reviews, including this one :).

I would like to thank my company too for allowing me to contribute Drupal via this program and Google for giving me an opportunity to participate in this great program.

 

 

Aug 10 2016
Aug 10

This year’s Google Summer of Code is slowly coming to an end. I am working on latest steps to complete the project as planned. In the previous blog post, I was writing about the final code polishing of Mailhandler, while the focus of last week (#11) was to improve the overall project documentation. Before the project wrap-up blog post, I am going to write about the real use-cases for Mailhandler.

5 steps to create secured user-content-driven Drupal website

One of the best use-cases for Mailhandler would be for media publishing Drupal-based websites. Those websites usually have different user roles for content creators, publishers, editors, administrators… That means a very different set of permissions for each role. For instance, one website could allow its users to create site content. Users could submit it either through a website or by sending a signed email using Mailhandler.

In order to enable users to create content by sending an email, an administrator would need to follow these simple 5 steps:

  1. Enable authenticated users to post nodes for a specific content type (e.g. Users posts).

  2. Set-up an email address that users will send content to.

  3. Enable Mailhandler module and make sure gnu_pg PHP extension is enabled on the web server.

  4. Create a new deliverer in Inmail to fetch new emails. This can be done by using an IMAP deliverer.

  5. Set a content type in the (MailhandlerNode) handler configuration that will be used to create content in.

By completing all the steps, a Drupal website is ready to accept users submissions. Since we are going to use PGP-signed emails which add an additional layer of security, the following steps are needed on the user side:

  1. Log in to the account and update your GPG public key. PGP-signed messages are signed with a private key of a user and verified on the Drupal website with the corresponding public key. PGP method of authentication is briefly explained in this blog post.

  2. The email address in the user account needs to match to the address user wants to send emails from.

  3. The subject needs to begin with [node] part. This is a technical term and tells our plugins about the referenced entity type.

  4. The final step is to write your article and send the email!

Voila! The user created content is available on the website. Since it was digitally signed, it is guaranteed the message was not changed in transmission and the user can not deny sending and signing the message.

Some web hosting services don’t support gnu_pg PHP extension by default. However, you can still benefit from Mailhandler by using a less secure From email address method of user identification. In order to use it, you will need to enable Message Sender Analyzer.

The above use-case represents one part of the Mailhandler features. The module can be used in a similar way to post comments via email, create ads or to make any other email integration with “node” entities out-of-the-box.

To allow end-users and developers an easy start with the module, we have been improving project documentation a lot. A Github pull request has been submitted and passed for the review to my mentors. All Inmail analyzers and handler plugins provided by Mailhandler will be documented and described in details. Also, the project will get a ReadMe.MD file that will consist of the module description, installation, configuration and how-to sections.

Also, I would like to inform you that lead maintainer of the Mailhandler, Dane Powell recognized the efforts we made this summer and gave us write access to the original repository. Thanks to him, we will be able to merge our Github repository and a sandbox project to the main module. This is one step forward to releasing a stable version of Mailhandler and a duty to keep contributing to Mailhandler in the future too.

The plan for the following week is to merge the documentation pull request and work on remaining Inmail issues that we started earlier. Additionally, the final project evaluation starts in less than a week and I will spend some time to prepare for it as well.

Drupal 8 module demo: Mailhandler from Milos Bovan on Vimeo.

Aug 03 2016
Aug 03

This blog post summarizes week #11 of the Google Summer of Code 2016 project - Mailhandler. Time flies and it is already the last phase of this year’s Google Summer of Code 2016. The project is not over yet and I would like to update you on the progress I made last week. In the last blog post I was writing about the problems I faced in week 10 and how we decided to do code refactoring instead of UI/UX work. The plan for the last week was to update Mailhandler with the newly introduced changes in Inmail as well as work on new user-interface related issues. Since this was the last week of issues work before doing the project documentation, I used the time to polish the code as much as possible.

As you may know, Inmail got new features on the default analyzer result. Since this change was suggested by Mailhandler, the idea was to remove Mailhandler specific analyzer result and use the default one instead. It allows the core module (and any other Inmail-based module) to use the standardized result across all enabled analyzers. The main benefit of this is to support better collaboration between analyzer plugins.
Even though Mailhandler updates were not planned to take a lot of time, it turned to be opposite. Hopefully, the long patch passed all the tests and was fixed in Use DefaultAnalyzerResult instead of Mailhandler specific one issue.
It was needed to not only replace the Mailhandler-specific analyzer result but to use user context and context concept in general as well. Each of the 5 Mailhandler analyzers were updated to “share” their result. Also, non-standard features of each of the analyzers are available as contexts. Later on, in the handler processing phase, handler plugins can access those contexts and extract the needed information.

The second part of the available work time was spent on user interface issues, mostly on improving Inmail. Mailhandler as a module is set of Inmail plugins and configuration files and in discussion with mentors, we agreed that improving the user interface of Inmail is actually an improvement to Mailhandler too.
IMAP (Internet Message Access Protocol) as a standard message protocol is supported by Inmail. It is the main Inmail deliverer and UI/UX improvements were really needed there. In order to use it, valid credentials are requested. One of the DX validation patterns is to validate those credentials via a separate “Test connection” button.
 

IMAP test connection buttonIMAP test connection button

In the previous blog posts, I mentioned a power of Monitoring module. It provides an overall monitoring of a Drupal website via nice UI. Since it is highly extensible, making Inmail support it would be a nice feature. Among the most important things to monitor was a quota of an IMAP plugin. This allows an administrator to see the "health state" of this plugin and to react timely. The relevant issue needs a few corrections, but it is close to be finished too.

Seeing that some of the issues mentioned above are still in “Needs review” or “Needs work” state, I will spend additional time this week in order to finish them. The plan for the following week is to finish the remaining issues we started and focus on the module documentation. The module documentation consist of improving plugin documentation (similary to api.drupal.org), Drupal.org project page, adding a Github read me, installation manuals, code comments, demo article updates and most likely everything related to describing the features of the module.

Jul 27 2016
Jul 27

This blog post summarizes week #10 of the Google Summer of Code 2016 project - Mailhandler.

In the last blog post, I was writing about the comment and demo module improvements. This blog post will provide an overview of the work done in the past 7 days. Even though the plan was to work mostly on UI/UX issues we ended up in code refactoring.

During the last meeting with my mentors we identified 3 key Inmail issues to work on: Lack of standard result in collaboration of analyzers, Support switching the user context and Provide a hook_requirements fed by plugin instances. We agreed those issues will provide better overall value in the integration of Mailhandler and Inmail modules. It will allow Inmail to implement ideas from Mailhandler, make them generic in a way both modules can benefit from.

Lack of standard result in collaboration of analyzers was identified as the main blocker to achieve analyzer collaboration. After a long discussion and 7 patches, it was finally committed. As a result, Inmail will have a default analyzer result which can be extended sequentially by all enabled analyzers. As this was a big change in core Inmail module, there are several follow-ups created.

Another Inmail issue Support switching the user context was dependent on the default analyzer issue. It uses AccountSwitcher service which completely switches the user context to the given user/account. That is done after the handlers run. In case the account switching mechanism was activated, we make sure it is switched back after the handlers-processing. On a handler level, we can use \Drupal::currentUser() and be sure it represents the identified user sender or an anonymous user otherwise.

Last but not least, I have been working on Provide a hook_requirements fed by plugin instances. The goal of this issue is to create a way for each of the Inmail plugins (analyzers, deliverers, handlers) to provide information about its runtime requirements. They can be PHP extension requirements, valid credentials etc. This information is displayed on “Status report” page (admin/reports/status) or processed by contrib modules like Monitoring.

Image removed.PGP Analyzer requirements

Inmail plugins can produce several issues with unmet requirements. As displayed in the picture above, PGP Analyzer needs gnupg PHP extension in order to work with signed messages. On the other side, an IMAP deliverer needs valid credentials to be functional.

Since the most of the Inmail issues mentioned above were committed, Mailhandler module will need adaption which is going to be my focus for this week. Also, I will analyze the code of the module and try to simplify it. Besides the mentioned, I will work on Inmail UI/UX issues which will be described in the next blog post.

Jul 20 2016
Jul 20

During the 8th week of Google Summer of Code 2016, we have started with adding support for posting comments via email. After getting the feedback from my mentors, there was some space to improve proposed solution. The suggestions were accepted and briefly explained below.

Comments in a submodule

As comments are supported through new handler plugin (MailhandlerComment), we decided to move it into a submodule - mailhandler_d8_comment. Following this approach, we can avoid too many dependencies on the main module. The submodule features: Inmail config entity that represents the handler, the plugin class and the related test coverage.

Configurable referenced entity type

With configurable referenced entity type of processed comments, we can support not only node entities but all the other “commentable” entities. In my opinion, this is a nice feature for site administrators in case they want to allow posting comments (for their articles or custom entities) as easy enough as sending an email.

Strict validation

Validation is the important topic in software development in general. In Drupal 8, there is an API made specifically for entity validation - Entity Validation API. It is recommended to use it before saving an entity. However, entity validation does not work as expected in a case of creating comments via API. The referenced entity ID and its bundle were not validated which required us to find a different approach. To accomplish this, we had to implement custom validation checks. They consist of:

  • Entity type validation - entity type is “commentable”

  • Referenced entity ID validation - referenced entity with provided ID actually exists

  • Bundle validation - identified entity bundle supports comments


Last week, besides the improvements made on the comment feature, I was working on the demo module improvements. The pull request has been submitted on Github and available for review. This module serves as an example module to show features of Mailhandler. It creates a sample “Mailhandler” content type (with a body field) and a new user with permissions to add content for “Mailhandler” content type and post comments. The GPG key field of this user was populated  with a sample key (both public and private GPG keys were added to the module) as well. Since last week, the example messages - sample comment and PGP clear-signed, MIME and MIME HTML emails are part of the demo module too. By enabling mailhandler_d8_demo, exploring Mailhandler features becomes very straightforward.

[embedded content]

Drupal 8 module demo: Mailhandler from Milos Bovan on Vimeo.

Also, the demo module adds a sample article attached to the front page. The idea is to have a descriptive article about Mailhandler features. Its content will be extended during the “documentation week”. Next week, I will be working on improving overall user experience and user interface of Mailhandler.

 

 

Jul 15 2016
Jul 15

The overall test coverage of Mailhandler module has been improved in the week 7 of Google Summer of Code. The plan for the week 8 was to implement feature for posting comments by sending an email.

Similarly to MailhandlerNode (handler for nodes), we had to create a new config entity: inmail.handler.mailhandler_comment and a handler plugin class. Since comments will have limited support, during the last weekly meeting with my mentors (Miro and Primoz), we decided not to add more analyzers as proposed first, but rather to move comment specific business logic to MailhandlerComment Inmail handler plugin.

In order to simplify the logic in the comment handler, EntityTypeAnalyzer was updated to support partial entity type matching. The entity type was extracted from the subject independently of the second part, which can be bundle or entity ID in case of comments.

The current steps in the comment handler are:

  • Assert we are dealing with comments (the identified entity type is comment)

  • Parse the referenced entity ID from the mail subject: [comment][#entity_id]

  • Validate (authenticate and authorize) a user

  • Create a comment entity if all previous conditions are met

The pull request on Github was already created and it will request additional updates after it received some nice suggestions from my mentor.

The Inmail issue Lack of standard result in collaboration of analyzers progressed well during the last week. After several feedbacks and broad discussion, it is currently in “Needs review” state. In my opinion, it is quite close to be fixed and we will be able to implement the standard analyzer result object into Mailhandler module very soon.

Also, last week I made a few UX improvements in the module.
Inmail demo now supports sample mail messages from mailhandler_d8_demo module. As a related issue, PGP-signed sample mails were added to the demo.

The Mailhandler Demo is our focus for the following week. It will be extended with a sample Mailhandler user with already preconfigured Inmail settings, PGP keys and relevant form and display updates. The goal is to provide an easy start for new Mailhandler users. The progress made on the module so far, will be presented as a short (video) demo. Stay tuned!

Jul 06 2016
Jul 06

The coding period of Google Summer of Code 2016 has been continued after midterm evaluation. After splitting the Mailhandler analyzer into more specific and independent analyzers for different parts of an email message (sender, entity type, PGP, body, footer), last week I was working on providing test coverage for those.

The current tests are mostly written as kernel tests because of their speed of execution. MailhandlerNodeTest represents an integration test for the node handler and tests the whole process of Inmail analyzers and handlers.

Newly written tests:

  • SenderAnalyzerKernelTest - covers the use case when a user is identified and when a user is not identified
  • PGPAnalyzerKernelTest - tests assertions of PGP-signed messages which inlude body, sender etc
  • FooterAnalyzerKernelTest tests plain mail messages with and without the message footer
  • EntityTypeAnalyzerKernelTestcovers entity type and bundle pair of the mail subject.
  • SenderAnalyzerKernelTest covers the mail sender detection using From mail header field.

As they were all similar in the implementation, AnalyzerTestBase was added. It contains the list of required enabled modules and set up configuration for easier analyzer-specific work. 

Regarding the web tests, I extended MailhandlerWebTest with "Manage display" assertions of GPG key field which can be displayed via the public key, GPG key's fingerprint or as both properties.

As previously mentioned I created a few inmail issues which will allow for a better DX. Here is a short update on status of those issues:

The plan for the next week seems quite interesting. Besides the mentioned Inmail issues, I will be working on adding support for creating comments by sending an email. All analyzers implemented in the previous week will be used as a part of new comment handler. I am looking forward to enriching Mailhandler with one more feature.

Jun 28 2016
Jun 28

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

Jun 21 2016
Jun 21

This is the 5th blog post of the Google Summer of Code 2016 project - Mailhandler.

Implementing authentication and authorization for a mail sender provided an additional layer of security for Mailhandler project. The module was extended to support both PGP signed and unsigned messages.

The goal for the last week was to create a mail Footer analyzer and to add support for node (content) type detection via mail subject. The pull request has been created and it is in the review status. This analyzer has a purpose of stripping the message footer/signature from the message body. As of now, 2 types of signature/footer separators are supported:

  • -- \n as the separator line between the body and the signature of a message recommended by RFC 3676
  • On {day}, {month} {date}, {year} at {hour}:{minute} {AM|PM} pattern which is trickier and currently used by Gmail to separate replied message from the response.

First of all, we had to create inmail.analyzer.footer config entity and the corresponding analyzer plugin - FooterAnalyzer. Since footer, subject and content type properties are relevant for all types of mail messages supported by Mailhandler, these properties were put in MailhandlerAnalyzerResultBase class.

FooterAnalyzer currently depends on the analyzed result provided by MailhandlerAnalyzer. The reason why one plugin depends on another is to support PGP signed messages. MailhandlerAnalyzer will try to analyze the message body of signed (and unsigned) messages and extract the actual mail body. Next, FooterAnalyzer will parse the processed body stored in MailhandlerAnalyzerResult. As mentioned above, the footer analyzer currently supports footers separated by -- \n and On {day}, {month} {date}, {year} at {hour}:{minute} {AM|PM} lines. The content after these lines is put into the footer property of the analyzer result. In case the body message has one of the supported separators, detected footer is stripped out from the actual message body.

Furthermore, the content type detection via message subject has been implemented. As we are going to support creating comments via email in the following weeks, we had to create a “protocol” that will allow us to differentiate between nodes and comments. We agreed to add [{entity_type}][{bundle}] before the actual message subject. For now, only node entity type and its bundle (content/node type) are parsed and extracted. All the assertions of the analyzed message are happening in the handler plugin (MailhandlerNode). The handler plugin will check if the configured content type is set to “Detect” mode and if so, it will get the parsed content type and create an entity of the parsed node type.

This week, students and their mentors are requested to submit mid-term evaluations. The evaluation represents a sum of the project after 5 weeks of the work. By finishing FooterAnalyzer, Mailhandler is now capable of processing signed (and unsigned) emails, extracting the actual body and creating a node of the detected node type for an authorized user.

The plan for the next week is to extend the project with validation support. We will use entity (node) validation and extend content type to bundle validation too. Also, I will work on splitting the Mailhandler analyzer to the smaller analyzers and adapting the handler to the changes.

Jun 14 2016
Jun 14

This blog post summarizes the third week of the Google Summer of Code 2016 project - Mailhandler.

As mentioned in the previous blog post, the Mailhandler prototype for Drupal 8 has been finished. The prototype has already one of the main features implemented - processing mail messages and creating nodes. However, processed messages could be created by anyone which is not really nice for a module aiming to be used in production. To solve this problem, I've been working on user authentication implementation for almost a week.

The goal was to authenticate a user (sender of an email) before doing any mail processing. The meta issue with its child issues formalizes the requirements.

An obvious way to identify a mail sender is by checking the From field from the mail header. As this field is required to be present in mail headers (RFC 2822) we can assume we will always be able to identify the sender's mail address.
While writing a blog post about building a prototype, I acquainted you with Inmail. This is the module we are going to rely on to process mail messages. Inmail has a nice concept of plugins separated into deliverers, analyzers, and handlers. Deliverers are used to specify where a mail is coming from, analyzers to identify different types of messages and handlers to do some actions with mail messages and analyzer results. Last week, I already added a handler plugin and here I am going to talk about analyzers.

I started implementing an Inmail analyzer plugin and named it MailhandlerAnalyzer. It inherits AnalyzerBase from Inmail and currently has only one method - analyze() which accepts $message (represents a mail message entity) and processor_result (collects outcomes of a single mail processing pass) parameters. To preserve analyzer results, MailhandlerAnalyzerResult is created with $sender, $user and $body properties. The $sender will represent a sender's mail address (obtained from From mail header field), $user is a user entity in the current system and the $body is analyzed message body. After populating those fields in the analyzer, the job of MailhandlerNode is to authenticate and authorize the sender. If the conditions are met (user is validated) the handler will process the message and do the actions (create a node). This gives us a basic level of security.

However, From mail handler field can be faked by a malicious user. To bridge this obstacle, we introduced support for digitally signed emails. By its definition: digital signature is a mathematical scheme for demonstrating the authenticity of digital documents and it provides:

  • Authentication - since the secret (private) key is bound to a specific user, successful signature verification will show the identity of the sender
  • Integrity - it guarantees the message was not changed during transmission. Any change of the message content after signing it invalidates the signature
  • Non-repudiation - a user can not deny sending and signing the message

Handling digital signature is not supported in PHP by default and we had to find the tools to do it. We decided to use GnuPG implementation of the OpenPGP (Pretty Good Privacy) standard defined by RFC 4880 and gnupg PHP extension. If you are not familiar with the concept of digital signature I would recommend you looking into this ~2 minutes read.

As a starting point, we have to add mailhandler_gpg_key field to store GPG Key for each user. I wanted to preserve public_key and fingerprint properties for each key and decided to go with custom field type. Drupal.org documentation provides a nice explanation how to create a custom field type, corresponding widgets and formatters in Drupal 8.

Mailhandler GPG Key fieldMailhandler GPG Key field

The next thing in our PGP journey is to extend analyzer and handlers to deal with signed messages. Usually, when handling emails, you will have to deal with regular expressions a lot. This case is not an exception. A new method called isSigned() is added to MailhandlerAnalyzer which analyzes the message and returns a boolean value. While we are dealing with messages at the low level, isSigned() populates the context data in case of signed messages. Context consists of:

  • PGP Type - the signed message could be inline-signed (clear-text signature) or as nowadays standard PGP/MIME.
  • Signed text - extracted the actual body without PGP signature
  • Signature - PGP signature

Populating the general result properties of the analyzer result instance (In case of signed messages MailhandlerAnalyzerResultSigned), the analyzer finishes its job. At this point, we can analyze the signed message and be sure if we are dealing with signed or unsigned mail messages.

Next, we have to adapt our handler to support signed messages too. That looks easy, as all the hard work is completed by the analyzer. The only thing we have to do is to verify the signature. We do that by getting the signed text and signature from the analyzer result and pass them to gnupg_verify() function. If the signature is valid and the corresponding user's GPG key is not disabled, revoked or expired we will continue the handling process. One last step to check before creating a node is to assert the user is authorized for that action.

To summarize, implementing support for digitally signed emails certainly provides an acceptable level of security for Mailhandler module. Keep in mind, that you will need to have GnuPG PHP extension enabled on your server to get GPG support. In either way, you will benefit from Mailhandler's default authentication system. The interesting thing about last week is that authentication support produced more than 1,2k new lines of code in the Github pull request

Next week, I am going to work on footer detection in a mail message. This will allow us to remove any unnecessary and unintended content from a node body. To support all those features, most of the work will be done in the analyzer. The mid-term evaluation period starts in less than a week which means the next week will be used to do preparation for it as well.

Over and out.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web