In the cloud era, hosting-based email services have become a common business model. Various entities can participate in the email delivery process. However, the intermediate paths of email delivery have received little attention. In particular, the vulnerabilities and centralization of email intermediate paths have already posed real-world security threats. This paper conducts the first systematic analysis of intermediate paths of email delivery, aiming to understand dependence patterns and characterize the centralization. In collaboration with a large email service provider, we collected Received headers from email reception logs spanning nine months and reconstructed the complete intermediate paths of 105M clean emails. Our results reveal that Microsoft is the dominant provider of intermediate paths, participating in 66.4% of emails. We find that 86.9M (82.7%) emails rely on third-party providers in intermediate paths, and 9.1M (8.7%) paths involve multiple providers. Email signature providers frequently appear in cross-vendor intermediate paths. In addition, we reveal significant differences in the regional dependencies and centralization of email intermediate paths across countries and continents. The centralization observed in email intermediate paths also differs from incoming and outgoing servers. We hope our work prompts more attention to email intermediate paths to enhance the security of the email ecosystem.

Abnormal email bounces seriously disrupt user lives and company transactions. Proliferating security protocols and protection strategies have made email delivery increasingly complex. A natural question is how and why email delivery fails in the wild. Filling this knowledge gap requires a representative global email delivery dataset, which is rarely disclosed by email service providers (ESPs).

To protect user DNS privacy, four DNS over Encryption (DoE) protocols have been proposed, including DNS over TLS (DoT), DNS over HTTPS (DoH), DNS over QUIC (DoQ), and DNS over HTTP/3 (DoH3). Ensuring reachability stands as a prominent prerequisite for the proper functionality of these DoE protocols, driving considerable efforts in this domain. However, existing studies predominantly concentrate on a limited number of DoT/DoH domains or employ a restricted subset of vantage points (VPs).

Webmail, protected by the HTTPS protocol, only works correctly if both the server and client implement HTTPS-related features without vulnerability. Nevertheless, the deployment situation of these features in the webmail world is still unclear. To this end, we perform the first end-to-end and large-scale measurement of webmail service. For the server side, we first build an email address set with a size of 2.2 billion. Then we construct two webmail domain datasets: one contains 21 k domains filtered from the email address set; the other only includes 34 domains but supports more than 75% of the 2.2 billion email addresses. After performing a comprehensive measurement on these two webmail domain datasets, we find that some features are poorly deployed. Furthermore, we also rank servers by analyzing the properties of HTTPS-related features. For the client side, we investigate implement of HTTPS-related features in 50 different combinations of web browsers and operating systems (OSes). We find that even the latest browsers have poor support for some features. For example, Firefox in all OSes does not support CT. Our findings highlight that the full deployment of the security features for the HTTPS ecosystem is still a challenge, even in the webmail service.

The DNS privacy protection mechanisms, DNS over TLS (DoT) and DNS over HTTPS (DoH), only work correctly if both the server and client support the Strict Privacy profile and no vulnerability exists in the implemented TLS/HTTPS. A natural question then arises: what is the landscape of DNS Strict Privacy? To this end, we provide the first longitudinal and comprehensive measurement of DoT/DoH deployments in recursive resolvers, authoritative servers, and browsers. With the collected data, we find the number of DoT/DoH servers increased substantially during our ten-month-long scan. However, around 60% of DoT and 44% of DoH recursive resolver certificates are invalid. Worryingly, our measurements confirm the centralization problem of DoT/DoH. Furthermore, we classify DNS Strict Privacy servers into four levels according to daily scanning results on TLS/HTTPS-related security features. Unfortunately, around 25% of DoH Strict Privacy recursive resolvers fail to meet the minimum level requirements. To help the Internet community better perceive the landscape of DNS Strict Privacy, we implement a DoT/DoH server search engine and recommender system. Additionally, we investigate five popular browsers across four operating systems and find some inconsistent behavior with their DNS privacy implementations. For example, Firefox in Windows, Linux, and Android allows DoH communication with the server without the SAN certificate. At last, we advocate that all participants head together for a bright DNS Strict Privacy landscape by discussing current hindrances and controversies in DNS privacy.