MedTrends Routing Engine not delivering e-mail

Dan Alvarado asked for assistance troubleshooting this
problem while I was in El Paso. This is not, necessarily,
a bug report; however, further troubleshooting cannot
be done without developer access and perspective.

SYNAPSIS:

E-Mail generated by the MedTrends web pages
successfully deliver e-mail; however, messages
generated by the Routing Engine are not being delivered
to the users.

CREATE THE PROBLEM:

1. Ensure the Routing Engine is installed, configured
correctly, and running on a machine with ASPMail
installed.
1. Create a routing chain; ensure that your SSN is
subordinate to someone else's.
2. Ensure that a location is linked to your SSN.
3. Ensure that "Routable" and "NotifyAdmin" are both
set to TRUE on the 4106.
4. Submit a new 4106 to the location you are
responsible for.
5. Open the Routing Report and find the session.
6. Note the status from SendMail(); should state
that /e-mail was sent to name@domain.tld.

The web interface will send a mail to the administrator
of the survey notifing them that a new survey was
submitted. However, the message sent with SendMail()
will not get delivered.

SUSPICIONS:

Because the Routing Engine is compiled Visual Basic
program that runs as a service, has it's own
(independent) settings, and uses it's own internal
SendMail() component, I suspect that it is creating e-
mails that appear to be forged. As a result, either an
SMTP server in the chain is denying a relay (and not
delivering it) or spam filters are catching it and not
delivering it to the client.

PATH TO SUSPICIONS:

These conclusions are drawn from circumstantial, not
empirecal evidence. The first step in troubleshooting
this problem is to cut it in half and determine if the
problem is with MEPS or with the services MEPS depends
on (SMTP, Exchange, etc). After verifying the
configuration we performed a binary progression of the
following factors:

1. From Address: formatted correctly
(name@domain.tld) and incorrectly (name) to isolate
whether or not dependent services were catching mail
because of forged information. Note - not all tests
could be done on this factor.

2. To Address: To dave.andrus@eclipsys.com and
daniel.alvarado@amedd.army.mil to isolate whether the
problem is specific to amedd.army.mil exchange servers
or not.

3. SMTP Relay Servers: Set to atl-nt-
ex5.eclipsnet.com and amedwswbamc0003 to isolate
whether or not the problem is related to an SMTP
configuration problem.

4. E-Mail Methods: We used the e-mail test included in
the MEPS Admin Console, the routing engine by
submitting a 4106, and manually sending e-mail by
telnetting to the relay server on port 25 (and using
SMTP chatter to send messages).

The following outlines the results from each of the 24
possible tests:

Method From To SMTP
Result
------------- ------- ------- -----------------------
------------------------
Web Correct Dave amedwsw0003
Pass
Web Incrct Dave amedwsw0003
Pass
Web Correct Dan amedwsw0003
Pass
Web Incrct Dan amedwsw0003
Pass
Web Correct Dave atl-nt-ex5
Pass
Web Incrct Dave atl-nt-ex5
Fail (*1)
Web Correct Dan atl-nt-ex5
Pass
Web Incrct Dan atl-nt-ex5
Fail (*1)
RoutingEngine Correct Dave amedwsw0003
N/A (*3)
RoutingEngine Incrct Dave amedwsw0003
Fail (*2)
RoutingEngine Correct Dan amedwsw0003
N/A (*3)
RoutingEngine Incrct Dan amedwsw0003
Fail (No mail)
RoutingEngine Correct Dave atl-nt-ex5
Fail (*1, *3)
RoutingEngine Incrct Dave atl-nt-ex5
Fail (*1)
RoutingEngine Correct Dan atl-nt-ex5
Fail (*1, *3)
RoutingEngine Incrct Dan atl-nt-ex5
Fail (*1)
Manual Correct Dave amedwsw0003
Pass
Manual Incrct Dave amedwsw0003
Pass
Manual Correct Dan amedwsw0003
Pass
Manual Incrct Dan amedwsw0003
Pass
Manual Correct Dave atl-nt-ex5
Pass
Manual Incrct Dave atl-nt-ex5
Fail (*1)
Manual Correct Dan atl-nt-ex5
Pass
Manual Incrct Dan atl-nt-ex5
Fail (*1)

Note #1: atl-nt-ex5.eclipsnet.com was configured not
to relay or deliver mail to addresses other than those at
eclipsys.com. Both the FROM: and TO: addresses need
to have eclipsys.com in them or else the server refused
to send mail.

Note #2: The "notify admin" e-mail sent by the web
(MedTrends) was sent using an incorrectly-formatted
("mepsteam@wbamc) FROM: address to
dave.andrus@eclipsys.com on the WBAMC server, a
message was delivered to the BADMAIL folder stating
that the SENDER (not the recipient) had an
unauthorized e-mail address. The message generated
by the routing manager, however, disappeared. This is
a key indicator because it is the only inconsistency we
could find.

Note #3: the format of the FROM: address within the
routing manager was not configurable, and thus, not
tested.

WHERE CONFUSION EXISTS

The most confusing part of this problem is the
inconsistent behavior when the routing engine sent mail
through the WBAMC SMTP relay to
dave.andrus@eclipsys.com. Even though many
messages appeared to be delivered via this pathway, it
was the only one that resulted in a BADMAIL message
being generated. Even more confusing is that it stated
the SENDER, not RECIPIENT was invalid. This
inconsistency suggests that either the SMTP server is
handling bad mail differently, bad mail definitions are
different at different relays, or or the messages are
significantly different.

NEXT STEPS

To continue troubleshooting this, the following questions
must be answered:

1. Is the routing mangager using the SendMail() function
found in modMisc.bas?

2. E-Mail generated by the routine engine have a from
address as "mepsteam@wbamc"; however, we could not
find "mepsteam" in any of the .BAS modules (and thus,
could not determine which module was generating the e-
mail). Where is this e-mail being generated?

3. Does mail get delivered to clients when sent from the
routing manager using a correctly-formatted FROM:
address (mepsteam@wbamc.army.mil)?

4. Does mail get delivered to clients if the routing
manager uses the same sendmail() function in the .ASP
common components / settings (instead of just the
same code / settings)?