atom feed11 messages in net.sourceforge.lists.courier-usersRE: [courier-users] Trap all incoming...
FromSent OnAttachments
Bowie BaileyJul 15, 2005 7:24 am 
Sam VarshavchikJul 15, 2005 3:51 pm 
Bowie BaileyJul 18, 2005 8:56 am 
Jay LeeJul 18, 2005 9:07 am 
Bowie BaileyJul 18, 2005 9:30 am 
David GomillionJul 18, 2005 9:45 am 
Jerry AmundsonJul 18, 2005 10:37 am 
Bowie BaileyJul 18, 2005 12:00 pm 
Bowie BaileyJul 18, 2005 12:07 pm 
Jerry AmundsonJul 18, 2005 2:52 pm 
Flavio StanchinaJul 21, 2005 8:31 am 
Subject:RE: [courier-users] Trap all incoming email
From:Bowie Bailey (Bowi@BUC.com)
Date:Jul 18, 2005 12:00:05 pm
List:net.sourceforge.lists.courier-users

From: David Gomillion [mailto:dgom@eyecarenow.com]

cour@lists.sourceforge.net wrote:

There is an external program that will be generating quite a bit of email to this server. Some of that mail will be delivered locally via a mail processing program and some of it will be for relay elsewhere. The processing program will resubmit some of the mail for delivery elsewhere.

We need to be able to run this for testing purposes without any of the external mail being delivered.

I sounds to me like the real work should be done in the external program that is generating the email.

Completely low-tech, I know, but why not change the delivery addresses of all external boxes to something internal, or even just a Yahoo drop-box to make sure it goes like you think it should? In some of my applications, up top I set a DEBUG variable. When it is TRUE or 1 (depending on the language), I do lots of funny things, like setting mailboxes to some of my free webmail accounts, printing debugs, pausing where I need to, preventing forking, etc. I find it extremely helpful when I need to test applications...

Lots of languages can even choose includes based on this stuff, so you can overload method names. I do this so when I'm debugging, authentication requests just get approved where I don't have enough info to test pieces of code because I am not privy to passwords, don't have access to the database, or am too lazy to build a full testing environment. Probably not the best coding technique, but in my experience, works really well in certain cases.

We have done some testing doing this type of thing, but the more changes you make for testing purposes, the less valid your test is. If I can find a way to block these outgoing emails, we can do a full test run with the final code without having to modify it for the test.

Other instances, I have to go the full 9 yards and build a lab environment that mirrors the production systems...

We have a test environment to a certain extent. What I am trying to do here is to set up some perimeter controls to ensure that none of the emails leave the test environment.

Bowie