4

We have a test environment which is pretty much a copy of the production environment for our Web applications.

In the past email addresses of customer data were scrubbed to avoid emails from test systems getting out into the wild. But our testers tell us that they would want to keep those email address unique, i.e. perfectly mapped to the real ones.

I thought that a usable method to scrub without losing information would be to remove all dots in the email address and then attach ".somewordlongerthanfourcharacters" to the computer part of the address. That would allow testers to know the real address of the customer ("herbert@ibmcom.someword -> herbert@ibm.com") plus we could set up an internal server named "someword" and have it receive emails for all subdomains of "someword".

Is that a useful idea or are there better methods to achieve this? Should I use a reserved test domain or something like that?

Zoredache
  • 130,897
  • 41
  • 276
  • 420
Andrew J. Brehm
  • 1,611
  • 7
  • 37
  • 57
  • Good question. I've seen the exact same issue come up with a production database being brought back as a test database. Our only solution was to have checks inside the code checking for the actual machine name of different servers. Your idea might actually work. – Chris Feb 09 '10 at 15:36

3 Answers3

2

I'd be concerned with all of the NDR's you'd get doing that... That could get extremely annoying.

Another option you could use would be to have an smtp server set as your development target and configure it to just accept and drop the outgoing messages. Hopefully your app has some kind of global variable defining the SMTP server to relay through.

squillman
  • 37,883
  • 12
  • 92
  • 146
  • Too dangerous. It's several applications and even if this worked, somebody might get the SMTP server setup wrong in the distant future (i.e. next year or possibly in three months when a a test environment for a new release is built). – Andrew J. Brehm Feb 09 '10 at 15:58
  • I wouldn't get any NDRs if I actually have a recipient server for all *.somewordlongerthanfourcharacters. The emails would be delivered and the applications would think that everything is fine, except that our testers can read the emails and customers cannot. – Andrew J. Brehm Feb 09 '10 at 16:04
1

Ensure that the test environment has its own DNS and map the production machine names to machines in the test environment. Make of the machines a mail relay (which you probably should do in production as well, rather than having all of the stuff sitting on the same host name) and just configure the test mail relay to do nothing.

If you're relying on the smtp server on the local box you should probably give it an alias, on the assumption that you might end up with too much load on the box and want to push the email through a different server.

Timo Geusch
  • 458
  • 1
  • 4
  • 9
  • Not good enough. We might want to emails to be sent and to be identifiable as having gone to different people. Own DNS fails if any engineer in the future makes a simple mistake and fails to set up the DNS infrastructure for a test environment – Andrew J. Brehm Feb 09 '10 at 16:08
  • There's nothing to stop you from sending emails to somewhere that isn't the bit bucket. If you control the DNS, you can always point the 'outgoing' SMTP server at some mock server that allows you to verify you sent the emails correctly. Also, from your comment above I take it you don't have a permanent test environment set up? I would strongly urge you to do that, if you don't you open yourselves to all sorts of interesting, non-reproducable problems. I'd create a VM or a bunch of VMs that contain the correct setup so that the engineer only has to drop the new software into it. – Timo Geusch Feb 09 '10 at 16:49
  • I don't control the DNS, company IT do. We have nine test environments constantly running, all below user access test level. I don't know how many user access test environments that team has. A bunch of VMs wouldn't help, a single test environment consists of about 30 servers plus other infrastructure. Test environments are perdiodically rebuilt four times a year in groups for quarterly releases. – Andrew J. Brehm Feb 09 '10 at 17:00
  • Ah, fair enough. Are you relaying out via a separate SMTP server or are you using local SMTP servers? – Timo Geusch Feb 09 '10 at 17:28
  • It's local SMTP servers but there could be any number of them and modules of applications could be hard-coded to use specific ones. I have to take such possibilities into account. – Andrew J. Brehm Feb 09 '10 at 21:49
1

I've used that solution in the past. Appended something like .test.local to all the email addresses. If you have control over DNS, then you can create an internal DNS domain & setup a mail server with a catch all address for testing to avoid all the NDR's.

Of course the biggest concern is what happens when someone 'forgets' to scrub the data & runs tests?

Advice on what to append? make it something that isn't resolvable on the internet i.e. .local

Nick Kavadias
  • 10,796
  • 7
  • 37
  • 47
  • In that case the other mechanisms in place will hopefully catch the emails before they run away. I am ignoring the problem of forgetting to scrub while looking for the best method to scrub. The problem of unscrubbed data is SEP (somebody else's problem). – Andrew J. Brehm Feb 09 '10 at 15:59
  • Appending is not enough... a parser somewhere might decide that herbet@ibm.com.test.local is actually herbert@ibm.com (because somebody wrote a parser that "knows" what an email address looks like). OTOH replacing "ibm.com" with "test.local" does not preserve the fact that herbert@ibm.com and herbert@sun.com are two different customers (a difference the testers want preserved in test environments). – Andrew J. Brehm Feb 09 '10 at 16:02
  • yikes! in that case strip out all the dots after at @ & append .example.com that'll look real & is reserved :-) – Nick Kavadias Feb 09 '10 at 16:08
  • So you think that my idea is probably the best solution? – Andrew J. Brehm Feb 09 '10 at 16:19
  • yes. can't think of anything better – Nick Kavadias Feb 09 '10 at 22:33