Salesforce Marketing Cloud: NOT an open mail relay
There's an online tester out there (I'm not sure which one) that seems to be flagging Salesforce Marketing Cloud infrastructure as having an open relaying mail server. This warning is a false positive; the infrastructure does not actually relay mail for spammers (or indiscriminately for anyone else); the specific servers and particular processes are configured to accept all mail, then silently discard mail that doesn't match any of the specific mail handling requirements built into the SFMC "Reply Mail Management" functionality.
What's an Open Mail Relay?
An open mail relay (also called an "open relay") is an email server configured to accept and forward email from any sender to any recipient on the internet, without authentication or restriction. This means anyone can use it to send ("relay") email messages to anyone else, even if they have no legitimate connection to the server.
In the prehistoric days of the modern internet, various mail server software packages shipped configured as open relays, right out of the box. Sometimes by mistake, and sometimes on the theory that an open relaying mail server was a good thing to help promote an open and cooperative internet.
Before SMTP auth and OAuth, email submission/sending for roaming users was also once a lot more tricky than it is today. Email admins sometimes attempted to secure their mail services by implementing hacks that required you to check your mail via IMAP or POP3 before you could submit mail (relay mail) from your laptop while connecting from an unknown network. These kind of configurations were complicated, kludgy and confusing. Some admins chose to just leave their mail server fully open to relaying, because of the pain and annoyance associated with these restrictions.
Open relaying mail servers were broadly utilized by spammers in the 1990s to slingshot spam to internet users. Because they would relay mail indiscriminately, meaning that they accept any email handed off to them, then happily forward that mail on to other internet users, they were exploited by bad guys to get around the common IP address-based blocks that many email server administrators (and the first blocklist publishers) implemented in their best efforts to keep spam from reaching their users' inboxes.
Email admins mad about spam would block spammer server IP addresses. Spammers, annoyed at being blocked, looked for open relaying mail servers to funnel their unwanted garbage through, to bypass that blocking.
This led to "open relaying" being considered a spam sign for a server, and many mail admins intentionally rejected any/all mail from open relaying mail servers, tracking those servers via reputation mechanisms like blocklists.
How would I know?
Back in the late 1990s, I created an anti-spam blocklist called the Radparker Relay Spam Stopper (RRSS), which eventually became part of the Mail Abuse Prevention System, one of the first anti-spam blocklists groups. My goal with this blocklist was to help make it much harder for spammers to misuse open relaying mail servers to shovel spam. (I also later created another open relay blocking blocklist and assisted with various other blocklists. Some tiny remnant of the MAPS RSS lives on today as part of Trend Micro's email security offering, I think. I never got any cut of that money, but I digress.)
The point being; I am intimately familiar with open relaying mail servers and how they work. I've monitored, tested, and even helped people fix many thousands of them over the years. It's in my spam fighting DNA.
Yes, but what of SFMC?
I worked for Salesforce Marketing Cloud (previously known as ExactTarget) for a good long time, somewhere around fifteen years, mostly in a "director of deliverability" role. In that time I helped clients address deliverability-related challenges, but I also worked in a product manager capacity and offered technical advice on various bits of functionality. I became very familiar with SFMC's Reply Mail Management (RMM) functionality and spent lots of time working with engineers to troubleshoot and improve the functionality, while simultaneously working with clients to configure and utilize it.
Even back then, clients would occasionally raise the concern that an online open relay tester would flag the Sender Authentication Package (SAP) or RMM infrastructure as an open relaying mail server. I had a standard script that I would use to patiently explain that the infrastructure was not actually exploitable. I explained truthfully that I tested it regularly myself, and that while it will accept inbound "open relay test" email messages, it never forwards them back to the relay tester.
That's the key necessary point of an open relaying mail server -- it can't just accept an email message for relay. It has to also forward that message on to another destination. Open relaying mail servers that "eat" messages themselves are not actually open relays and aren't usefully exploitable by spammers, because they don't actually "relay" mail.
This highlights a limitation of most open relay email testers, going all the way back to my spam fighting experiences back in the late 1990s. People assume that because step one of the test shows that a message was accepted, that the server must be exploitable. These tests were often incomplete and inaccurate; if a server doesn't actually relay the mail, you can't assume that it's an open relay. If you do so, you end up with false positive flagging of servers that are not actually problematic.
I knew this back in 1999 and it remains true today.
In Conclusion
TL;DR? Most online open relay testers are poorly implemented and can't be trusted. And, specifically, I know from personal experience that the SFMC email infrastructure used for their SAP and RMM functionality is not open to unrestricted email relay.
Could something change? Could they stand up a new server and configure it incorrectly in a way that leads to a security concern? I can't predict the future, but I can warn you that you need to make sure that you perform any security testing properly, otherwise you're going to get inaccurate warnings that do you no good.
There's an online tester out there (I'm not sure which one) that seems to be flagging Salesforce Marketing Cloud infrastructure as having an open relaying mail server. This warning is a false positive; the infrastructure does not actually relay mail for spammers (or indiscriminately for anyone else); the specific servers and particular processes are configured to accept all mail, then silently discard mail that doesn't match any of the specific mail handling requirements built into the SFMC "Reply Mail Management" functionality.
What's an Open Mail Relay?
An open mail relay (also called an "open relay") is an email server configured to accept and forward email from any sender to any recipient on the internet, without authentication or restriction. This means anyone can use it to send ("relay") email messages to anyone else, even if they have no legitimate connection to the server.Why is an Open Mail Relay Bad?
Open relaying mail servers were broadly utilized by spammers in the 1990s to slingshot spam to internet users. Because they would relay mail indiscriminately, meaning that they accept any email handed off to them, then happily forward that mail on to other internet users, they were exploited by bad guys to get around the common IP address-based blocks that many email server administrators (and the first blocklist publishers) implemented in their best efforts to keep spam from reaching their users' inboxes.Email admins mad about spam would block spammer server IP addresses. Spammers, annoyed at being blocked, looked for open relaying mail servers to funnel their unwanted garbage through, to bypass that blocking.
How would I know?
Back in the late 1990s, I created an anti-spam blocklist called the Radparker Relay Spam Stopper (RRSS), which eventually became part of the Mail Abuse Prevention System, one of the first anti-spam blocklists groups. My goal with this blocklist was to help make it much harder for spammers to misuse open relaying mail servers to shovel spam. (I also later created another open relay blocking blocklist and assisted with various other blocklists. Some tiny remnant of the MAPS RSS lives on today as part of Trend Micro's email security offering, I think. I never got any cut of that money, but I digress.)The point being; I am intimately familiar with open relaying mail servers and how they work. I've monitored, tested, and even helped people fix many thousands of them over the years. It's in my spam fighting DNA.
Yes, but what of SFMC?
I worked for Salesforce Marketing Cloud (previously known as ExactTarget) for a good long time, somewhere around fifteen years, mostly in a "director of deliverability" role. In that time I helped clients address deliverability-related challenges, but I also worked in a product manager capacity and offered technical advice on various bits of functionality. I became very familiar with SFMC's Reply Mail Management (RMM) functionality and spent lots of time working with engineers to troubleshoot and improve the functionality, while simultaneously working with clients to configure and utilize it.Even back then, clients would occasionally raise the concern that an online open relay tester would flag the Sender Authentication Package (SAP) or RMM infrastructure as an open relaying mail server. I had a standard script that I would use to patiently explain that the infrastructure was not actually exploitable. I explained truthfully that I tested it regularly myself, and that while it will accept inbound "open relay test" email messages, it never forwards them back to the relay tester.
That's the key necessary point of an open relaying mail server -- it can't just accept an email message for relay. It has to also forward that message on to another destination. Open relaying mail servers that "eat" messages themselves are not actually open relays and aren't usefully exploitable by spammers, because they don't actually "relay" mail.
This highlights a limitation of most open relay email testers, going all the way back to my spam fighting experiences back in the late 1990s. People assume that because step one of the test shows that a message was accepted, that the server must be exploitable. These tests were often incomplete and inaccurate; if a server doesn't actually relay the mail, you can't assume that it's an open relay. If you do so, you end up with false positive flagging of servers that are not actually problematic.
I knew this back in 1999 and it remains true today.
In Conclusion
TL;DR? Most online open relay testers are poorly implemented and can't be trusted. And, specifically, I know from personal experience that the SFMC email infrastructure used for their SAP and RMM functionality is not open to unrestricted email relay.Could something change? Could they stand up a new server and configure it incorrectly in a way that leads to a security concern? I can't predict the future, but I can warn you that you need to make sure that you perform any security testing properly, otherwise you're going to get inaccurate warnings that do you no good.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.