Email messages with and without a link
Email messages with a link
The Duke email system has always been a complex system combined with the Duke Email Pre-Processing System and the Office 365 environment. Users’ experiences have been affected by the performance of both the Duke Email Pre-Processing System and Office 365. In regards to the Duke Email Pre-Processing System, there could be inefficiencies in any one of the three pipelined stages: (1) malware checking, (2) address rewriting, and (3) destination resolving. In the first stage of malware
checking, Duke OIT uses the Proofpoint Target Attack Protection (TAP) service in the Email Pre-processing System to prevent emails from threats: malicious attachments and URLs. TAP rewrites URL by adding “ https://urldefense.proofpoint.com/v1/url?u= ” ahead of the original URL to show that this URL has been checked. Even if a URL is defended, it will still be continuously and dynamically checked later to guarantee its safety. If this URL contains malicious information, when the user clicks on it, the link will be blocked. The Duke OIT began to apply the Proofpoint Protection Service for the Duke Mail System in the Spring Semester, 2016 and the author wanted to investigate whether the application of the Proofpoint Protection Service would sacrifice much performance of email delivery. Therefore, this tool was designed to test the latencies of emails with and without a link. In regards to Office 365, the author measured how the diversity of network paths (emails sent from the Duke CoLab machine and emails sent from Amazon EC2) can affect the email delivery latency, though delivering emails within Office 365 is always beyond the Duke OIT’s control. Two comparisons were made to verify the author’s assumptions before this experiment. The first comparison is between emails containing a URL and emails that do not contain a URL. Because the Proofpoint checking occurs for a URL in the Duke Email Pre-Processing System and the author wanted to know if it took too long for Proofpoint TAP to check the URL link, the sample emails were divided into two categories: emails containing a URL and emails that do not contain a URL. The results showed that the emails containing a URL and that do not contain a URL have no difference in delivery latency. The second comparison is between emails sent from the Duke CoLab machine and emails sent from Amazon EC2, because the author wanted to compare if the diversity of network paths could affect the email delivery latency. The result showed that the latency of the emails going through the Duke Email Pre-Processing System was longer than that in Office 365 before January 18, 2017. The two kinds of latencies became very similar after this date. This was likely because that the Microsoft made some changes on that day to improve the performance of delivering emails within Office 365.
During monitoring Duke emails in the past several months (June 1, 2016 – February 6, 2017), the author discovered some important phenomena. These included long delay in address rewriting and the conversion of the structure of Duke email pre-processing system. First, the author discovered a problem of the long delay in the second stage of address rewriting in the four-stage pipelined email system. After adding six virtual machines by Duke OIT, the latency dropped by approximately a half. The second issue was that the four stage pipelined system was converted into three stages. This result was that the latency through Duke Email Pre-Processing System dropped to only 0 – 1 second from 40 or more seconds.
