Tweet
Bug: eSignal 7.2 Email Alerts cannot be sent to Microsoft IIS 5.1 SMTP Server
eSignal's Email Alerts can NOT be sent to an ISP or via a local network that uses Microsoft's email server product, IIS 5.1 SMTP Server, as the SMTP Host. This includes the SMTP Server that comes with Windows XP Pro (which is not installed by default).
This has been reported to eSignal.
Brad
The technical details for those interested...
eSignal abruptly ABORTs the TCP/IP connection before the email is completely sent because it thinks there is a protocol error in the intermediate handshaking response that the Microsoft server sends back to eSignal. This response tells eSignal that it successfully received what was sent and to continue sending the rest of the email. However, eSignal is not waiting for the complete response message - which is completely sent within milliseconds.
This problem was diagnosed by examining the TCP/IP network data stream between eSignal and the email server and using a SMTP server simulator. Using the emulator, email was successfuly sent ONLY if any response message sent to it from the SMTP Host was sent as a single network send. If the response stream was sent as multiple network sends, even if there's only milliseconds between them, eSignal aborts the TCP/IP connection. Since TCP/IP is a streaming protocol, not a packet-based one, eSignal should be handling this.
For example, eSignal WILL handle the following ok:
eSignal: MAIL FROM:<[email protected]><CR><LF>
SMTP Server: 250 OK<CR><LF> (server responses that it got the last part of the email ok)
However, it will ABORT the connection in the example below where the response is sent as two network sends, which is what I believe Microsoft's SMTP server does in this particular case:
eSignal: MAIL FROM:<[email protected]><CR><LF>
SMTP Server: 250 OK
eSignal: --- aborts connection immediately ---
SMTP Server: <CR><LF> (sends rest of response MILLISECONDS later)
eSignal's code to handle the response from the SMTP Host looks like this:
1) Get some TCP/IP data from the SMTP Host
2) Process it...
However, since TCP/IP is a streaming protocol, it SHOULD look like this:
1) Get some TCP/IP data from the SMTP Host
2) Is the message complete? (does it end with <CR><LF> - all SMTP messages end this way)
3) If not, go back and get some more data
4) Process it...
This has been reported to eSignal.
Brad
The technical details for those interested...
eSignal abruptly ABORTs the TCP/IP connection before the email is completely sent because it thinks there is a protocol error in the intermediate handshaking response that the Microsoft server sends back to eSignal. This response tells eSignal that it successfully received what was sent and to continue sending the rest of the email. However, eSignal is not waiting for the complete response message - which is completely sent within milliseconds.
This problem was diagnosed by examining the TCP/IP network data stream between eSignal and the email server and using a SMTP server simulator. Using the emulator, email was successfuly sent ONLY if any response message sent to it from the SMTP Host was sent as a single network send. If the response stream was sent as multiple network sends, even if there's only milliseconds between them, eSignal aborts the TCP/IP connection. Since TCP/IP is a streaming protocol, not a packet-based one, eSignal should be handling this.
For example, eSignal WILL handle the following ok:
eSignal: MAIL FROM:<[email protected]><CR><LF>
SMTP Server: 250 OK<CR><LF> (server responses that it got the last part of the email ok)
However, it will ABORT the connection in the example below where the response is sent as two network sends, which is what I believe Microsoft's SMTP server does in this particular case:
eSignal: MAIL FROM:<[email protected]><CR><LF>
SMTP Server: 250 OK
eSignal: --- aborts connection immediately ---
SMTP Server: <CR><LF> (sends rest of response MILLISECONDS later)
eSignal's code to handle the response from the SMTP Host looks like this:
1) Get some TCP/IP data from the SMTP Host
2) Process it...
However, since TCP/IP is a streaming protocol, it SHOULD look like this:
1) Get some TCP/IP data from the SMTP Host
2) Is the message complete? (does it end with <CR><LF> - all SMTP messages end this way)
3) If not, go back and get some more data
4) Process it...