<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>News on OutboxServer</title><link>https://outboxserver.com/news/</link><description>Recent content in News on OutboxServer</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 02 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://outboxserver.com/news/index.xml" rel="self" type="application/rss+xml"/><item><title>Email Delivery Introduces Security Risk Exposure</title><link>https://outboxserver.com/news/2026-10-02-email-delivery-introduces-security-risk-exposure/</link><pubDate>Fri, 02 Oct 2026 00:00:00 +0000</pubDate><guid>https://outboxserver.com/news/2026-10-02-email-delivery-introduces-security-risk-exposure/</guid><description>&lt;p&gt;You asked whether it&amp;rsquo;s a problem for your product teams to add &amp;ldquo;send an email&amp;rdquo; to their
applications by dropping in a provider&amp;rsquo;s SDK and an API key. My short answer: it&amp;rsquo;s a bigger
decision than it looks. When you integrate an application &lt;strong&gt;directly&lt;/strong&gt; with an email delivery
service, you take on a new trust relationship, new code, new dependencies, new long-lived secrets,
and often a new inbound endpoint. Each one is a way in. And because email is how your organization
talks to customers, partners, and employees, a compromise rarely stays inside the app that caused
it.&lt;/p&gt;</description></item></channel></rss>