ColdFusion Muse

ColdFusion email security Bug: Your mail in the wrong sent folder?

Mark Kruger August 21, 2013 5:00 PM ColdFusion Comments (8)

A recent conversation on CF-Talk piqued my interest. It turns out there is a tricky bug with regard to sending authenticated mail. Here at CF Webtools we have internal relays (protected, internal only IPs, listed in SPF and handling domain keys) whose sole purpose is to relay mail from our web servers - so we do not have "authenticated" email per se. But in the case of this bug (you can see the report here) it's possible for email from one user to wind up in the "Sent" folder of email from an entirely different user. Needless to say this is a security concern for those of you on shared servers especially.

Here are the conditions that need to be met for this to occur (as I understand it).

  • Server needs to be busy enough to be sending quite a bit.
  • Mail server handling the outgoing mail must do more than just relay the mail. It must put the mail relayed into the "sent" folder of the authenticated user. That's not a common behavior for most mail servers. In this case Google Apps Gmail fits the bill. In my experience most mail servers do not do this. Indeed, I suspect that the bug was really introduced by this "feature" of Gmail (or perhaps other mail servers).
  • The ColdFusion Administrator setting for "Maintain connection to mail server" (on the "mail" settings page) must be checked.
  • Mail must be sent:
    • By multiple users on the server using SMTP authentication (i.e. the username and password of their account needed to relay)
    • Sending to the same domain
Complicated? Not really. Let's think about it for a moment. Bob sends an email to his mom using with a user name of and a password of pooky. Bob's girlfriend Mary sends an email to her mom explaining what a dufus Bob is. She sends her message to with a username of and a password of sugarbear (I think Bob and Mary are made for each other).

Bob's message arrives at CF, which creates a connection and sends the mail. Meanwhile Mary's message arrives right behind it. ColdFusion, which has been instructed to maintain and reuse connections, thinks to itself, "Hmmmm... I already have an open connection to," and quick as a flash it sends Mary's email right behind Bob's down the same pipe.

But since Bob's connection was created with Bob's authentication properties this second email is placed in Bob's "sent" folder along with his own legitimate sent message requesting his Mom's recipe for cranberry chutney. The result? Bob see's Mary's email, learns that he is in fact a dufus as his father always claimed, collapses in tears, and a budding relationship is ended. I ask you - is it right for ColdFusion to rain on their emotional parade? Everyone needs someone right? Napoleon had his Josephine, Nicholas his Alexandra and of course Sonny had his share.

Anyway this is clearly a bug for 2 reasons. First, I sort of expect "maintain connections" to be a setting that affects the server I enter on the admin page (the default relay) - not every possible server a developer might specify. Second, it's clear to me that the authentication portion of an outgoing email connection is (or should be) something that uniquely tracks that connection. So a connection with one set of credentials should not match a connection with another set.

In any case this has some implications if your code meets the criteria above so make sure and handle it accordingly. Note, this affects ColdFusion 9 and 10 as I understand it.

  • Share:

Related Blog Entries


  • Wilgeno's Gravatar
    Posted By
    Wilgeno | 8/21/13 5:17 PM
    One would think that a "Connection" would include any authenticating information and thus a new request with different authentication information would require a new connection.
  • Mark Kruger's Gravatar
    Posted By
    Mark Kruger | 8/21/13 6:57 PM

    That would be my thought as well. But the are sort of thinking "globally" here. The CF admin has a relay setting and it's used by the entire server as the default... so why wouldn't the connection be reusable as well. At least I think that's the reasoning here. But it breaks down obviously.
  • snake's Gravatar
    Posted By
    snake | 8/21/13 7:12 PM
    shockingly this issue must have existed since always and no-one noticed it till now.
  • snake's Gravatar
    Posted By
    snake | 8/21/13 7:17 PM
    Here is a work around.

    to avoid this issue you should use your own domain name as the SMTP server so that it isn't the same as anyone else's and thus won't use their exisitng connections. Those using for example should create a CNAME record for pointing to
  • Mark Kruger's Gravatar
    Posted By
    Mark Kruger | 8/21/13 10:19 PM

    I'll post a follow up tomorrow on how that CNAME thing works. There's an additional step - namely that you have to change your own "server" property in your cfmail tag to point to your own dns entry (which is an alias for the other one).
  • Phillip Senn's Gravatar
    Posted By
    Phillip Senn | 9/26/13 12:31 PM
    I'm glad I took the time to read this when it came across my desk because we just had this scenario happen this morning, and I remembered reading about it.
  • Mark Kruger's Gravatar
    Posted By
    Mark Kruger | 9/26/13 1:09 PM

    Glad I could help :)

  • Rodrigo Munera's Gravatar
    Posted By
    Rodrigo Munera | 4/29/15 8:20 PM
    We encoutered the same issue with sendgrid. Have multiple accounts, some for marketing that will get lower reputation quicker, and others for mission-critical emails, like purchase confirmations, tracking info, etc. We've seen our messages cross accounts while the connection to the smtp server is open, meaning, sending a mission-critical email will open the connection with the whitelisted account, and then CF will send a mass marketing email meant to use other credentials using the whitelisted account. I've tested this issue locally and found that unchecking the "Maintain connection to mail server" causes CF to create a new connection on each mail message sent but are concerned about performance at high volumes.