3

I'd like to disable all email from being sent on our dev server even if server and credentials are used in the cfmail tag. I'd like the messages to go into the spool as undeliverable so that we can read them.

This is on windows.

EDIT - why? We currently have the mail server set as a dummy in the admin, but we specify a number of servers on various mail tags. Having been burnt once by a developer sending mail accidentally, we'd like to disable it entirely.

Mike Causer
  • 8,196
  • 2
  • 43
  • 63
J.T.
  • 2,606
  • 15
  • 31

2 Answers2

8

You could firewall against port 25 outgoing (make sure and excluded 127.0.0.1 as well if you are relaying locally). You would use iptables or Windows Firewall to stop outgoing port 25 connections. Your messages would be created by CF but the CF spooler, unable to deliver, would bounce them to the undeliverables folder.

Mark A Kruger
  • 7,183
  • 20
  • 21
  • This is definitely a good solution if one cannot exist in a ColdFusion neo XML or custom global override. – J.T. Apr 11 '12 at 16:44
  • For what you are trying to do I think it's your only viable option. Short of disabling the cfmail tag I don't think there's a way to do it using the app server config. – Mark A Kruger Apr 11 '12 at 17:11
  • Yeah, that's what I was thinking. Disabling the mail tag results in the usual access error. Even if it didn't, that would result in nothing ending up in the spooler as undeliverable. – J.T. Apr 11 '12 at 17:14
  • I'm going to choose this. This is the stop-gap "sledge hammer" that will have to work. The other answer is certainly the better choice if you have time or a limited scope. This choice does have risk because you put control outside of the application. – J.T. Apr 11 '12 at 19:36
  • I never have tried this but you might be able to simply edit your hosts file in your OS to have the mail server names point to an IP address that lacks a mail server. Could be as simple as doing entries like: 127.0.0.1 mail.mydomain.com if you lack a mail server on the Dev web server. – Snipe656 Apr 12 '12 at 15:29
  • Snipe - I love that idea... but it would require extra knowledge and your developers could still likely get around it (accidentally or on purpose :) – Mark A Kruger Apr 12 '12 at 15:35
7

Depending on how many cfmail tags you have, you might consider rewriting them to an abstraction of cfmail that you can then conditionally disable globally.

One example would be my own Mailer.cfc which allows for just that very use-case. http://www.bryantwebconsulting.com/docs/com-sebtools/mailer-cfc.cfm (see "Simulated Mailing")

Although I think Mailer.cfc would specifically address your problem, the broader point is that you can create an abstraction layer for functionality and then apply your own behaviors to it. This does entail some changes to code, but also provides a good deal of flexibility and control to your application.

Steve Bryant
  • 1,046
  • 5
  • 7
  • Cool tool and great documentation. – J.T. Apr 11 '12 at 17:41
  • This is basically what I have been doing for quite some time. Within my application.cfm or application.cfc depending on the age of the app I have a variable Application.DevFlag. Then I have a CFC I use for sending out all emails. The CFC if it knows it is in development will bypass all emails to whatever the support email address is for that application. This in turn allows me to ensure that emails would go to the correct people and look correct. My email CFC also handles some other needs like canned looks and so on. – Snipe656 Apr 11 '12 at 17:49
  • We had the same issue on a project in that we did not want any email going out whatsoever from our dev servers. We, too, got burned once. Once :). Anyway, I wanted to add a comment-based +1 for this approach. We updated our code base so that there was a single CFMAIL tag, housed in a Mailer.cfc that we used. In dev mode, it was easy to disable mailing. – craig.kaminsky Apr 11 '12 at 18:03
  • This is definitely a solution I would use given the lack of any global option to disable outbound mail if we needed to keep it within the application. It's something that was brought up, but were hoping to avoid it. With hundreds of mail tags, it means a lot of testing. If it were a handful, it wouldn't be a problem. – J.T. Apr 11 '12 at 19:31