none
SMTP server terminates connection before sending QUIT command RRS feed

  • General discussion

  • We have written a simple (standard .net tcp async logic) SMTP listener which listens on 25 port for incoming connections from other SMTP servers.

    It process all mandatory commands like FROM, RCPT TO, etc.

    With some servers it works well but, some SMTP servers (like Microsoft outlook) terminates connection before sending QUIT command and then re-send the same emails again and again.

    Anything we have missed?


    Assembler (.../z80/x86/x64...) the best language I've ever known

    • Changed type Fred BaoModerator Monday, March 10, 2014 3:16 AM The discussion is more suitable for this case
    Saturday, February 8, 2014 9:45 PM

All replies

  • Hello,

    >>We have written a simple (standard .net tcp async logic) SMTP listener which listens on 25 port for incoming connections from other SMTP servers.

    Could you please share how you written the listener?

    >>then re-send the same emails again and again.

    Please have a try to use try-catch to check whether it actually occurs an exception.

    Regards.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, February 10, 2014 9:31 AM
    Moderator
  • You are looking at two diffferent network layers.  One is the application layer and the other the transport layer.  I belive you have a race codition with the way you are closing your connections.  TCP does not specify what happens when both ends of a conneciton closes simultaneously which creates a race condition.  Differrent vendors implimented the  race condition differently.  To eliminate the race condition I usually recommend the following sequence when closing the connection

    1) Client application sends an application stop command to the server application.

    2) The server stops processing and send an application acknmowledge message to client.

    3) The server waits for a close event (initiaited by client closing the connection) before disposing

    4) The client closes the connection.  The server doesn't close the connection.  TCP only requires one end of the connection to close.


    jdweng

    Monday, February 10, 2014 10:40 AM
  • Hello,

    >>We have written a simple (standard .net tcp async logic) SMTP listener which listens on 25 port for incoming connections from other SMTP servers.

    Could you please share how you written the listener?

    >>then re-send the same emails again and again.

    Please have a try to use try-catch to check whether it actually occurs an exception.

    Regards.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Sometimes it closes connection right after and of DATA "\r\n.\r\n" and sometimes right before we are starting to send 250 OK

    Assembler (.../z80/x86/x64...) the best language I've ever known

    Monday, February 10, 2014 11:03 AM
  • You are looking at two diffferent network layers.  One is the application layer and the other the transport layer.  I belive you have a race codition with the way you are closing your connections.  TCP does not specify what happens when both ends of a conneciton closes simultaneously which creates a race condition.  Differrent vendors implimented the  race condition differently.  To eliminate the race condition I usually recommend the following sequence when closing the connection

    1) Client application sends an application stop command to the server application.

    2) The server stops processing and send an application acknmowledge message to client.

    3) The server waits for a close event (initiaited by client closing the connection) before disposing

    4) The client closes the connection.  The server doesn't close the connection.  TCP only requires one end of the connection to close.


    jdweng

    AS SMTP Protocol has standard "minimal" behaviour - any SMTP server has to recive command from other SMTP server that an email has been recieved, so in our case the behaviour is unpredictable

    Assembler (.../z80/x86/x64...) the best language I've ever known

    Monday, February 10, 2014 11:05 AM
  • our code is very simmilar to this example http://msdn.microsoft.com/en-us/library/system.net.sockets.tcplistener.beginacceptsocket(v=vs.110).aspx

    so nothing special


    Assembler (.../z80/x86/x64...) the best language I've ever known


    • Edited by vozmen Monday, February 10, 2014 11:07 AM
    Monday, February 10, 2014 11:07 AM
  • The problem isn't with the sample code.  The problem is what happens after the sample codel

    clientConnected.WaitOne();

    while(true){};

    What does you code do after the WaitOne is set?  Put a block using a while loop like in the code above and see if you get the results you are looking for?


    jdweng

    Monday, February 10, 2014 12:20 PM
  • We have two different threads - one thread is always looking for a new connections and the second one is processing any new connection

    Assembler (.../z80/x86/x64...) the best language I've ever known

    Monday, February 10, 2014 12:31 PM
  • Here is our code
    void StartListener(){
    
    while (true)
                {
                    lock (_lock)
                    {
                        if (!_isRunning) break;
                    }
    
                    try
                    {
                        tcpClientConnected.Reset();
                        Program.TraceMsg("Listener " + IP + " - " + PORT + " ready.", 3);
                        var client = listener.BeginAcceptSocket(new AsyncCallback(DoAcceptTcpClientCallback), listener);
                        tcpClientConnected.WaitOne();
                    }
                    catch (SocketException se)
                    {
                        Program.TraceMsg("ServerV2 SocketException:" + se.Message, 2);
                        Program.TraceMsg("ErrorCode: " + se.ErrorCode, 2);
                        Program.TraceMsg(se.StackTrace, 2);
                    }
                    catch (Exception ex)
                    {
                        Program.TraceMsg("ServerV2 Exception: " + ex.Message + ex.StackTrace, 2);
                    }
                }
    }
    

    void DoAcceptTcpClientCallback(IAsyncResult ar)
            {
                try
                {
                    TcpListener listener = (TcpListener)ar.AsyncState;
                    Socket client = listener.EndAcceptSocket(ar);
                    tcpClientConnected.Set();
                    SMTPServerV3 handler = new SMTPServerV3();
                    handler.Init(client);
                    ThreadPool.QueueUserWorkItem(new WaitCallback(ClientThread), handler);
                }
                catch (SocketException se)
                {
                    Program.TraceMsg("ServerV2 SocketException:" + se.Message, 2);
                    Program.TraceMsg("ErrorCode: " + se.ErrorCode, 2);
                    Program.TraceMsg(se.StackTrace, 2);
                }
                catch (Exception ex)
                {
                    Program.TraceMsg("ServerV2 Exception: " + ex.Message + ex.StackTrace, 2);
                    tcpClientConnected.Set();
                }
                finally
                {
                }
            }
    

    void ClientThread(Object StateInfo)
            {
                try
                {
                    (StateInfo as SMTPServerV3).Run();
                }
                catch (SocketException se)
                {
                    Program.TraceMsg("ServerV2 SocketException:" + se.Message, 2);
                    Program.TraceMsg("ErrorCode: " + se.ErrorCode, 2);
                    Program.TraceMsg(se.StackTrace, 2);
                }
                catch (Exception ex)
                {
                    Program.TraceMsg("ServerV2 Exception: " + ex.Message + ex.StackTrace, 2);
                }
            }

    And (StateInfo as SMTPServerV3).Run() just read from socket, processes SMTP commands and writes SMTP answer commands back

    Assembler (.../z80/x86/x64...) the best language I've ever known



    • Edited by vozmen Monday, February 10, 2014 12:55 PM
    Monday, February 10, 2014 12:48 PM
  • You can only have one connection with the same 3 items below

    1) Source IP address

    2) Destination IP address

    3) Port number

    I personally don't like the way microsoft has implimented the network classes.  I suspect the port (socket) isn't closing.  When a second connection is attempted it doesn't complete because the first connecton is opened.

    I believe microsoft made a change in the SMTP class between Net 4.0 and Net 4.5.  Net 4.0 the SMTP didn't have a dispose method.   The only way of closing a SMTP socket was to put the SMTP client in its own class and then dispose the instance of the class.  It was the only way of sending more than one SMTP mail message.

    I've been told that the new Net Libraries now have a SMTP dispose method.  I have never tried it so I don't know what happens.  I would start by using the cmd.exe command "Netstat -a" which wil give you a list of the UDP and TCP port numbers and the status of the ports.  Check to see port 25 is actually closing.  Make sure it sdoesn't get stuck in a half open half close state.


    jdweng

    Monday, February 10, 2014 1:19 PM
  • There is only one connection. We do not use .Net SMTP class - we use TCPClient class and we just read raw data from connection and write raw data to the socket.

    Connection is still only one per remote SMTP server and our IP - so what a you talking about is not relating to our case.

    Thank you


    Assembler (.../z80/x86/x64...) the best language I've ever known

    Monday, February 10, 2014 1:26 PM
  • Look for the TCP FIN message(s) in a sniffer.  See which end of the connection sends the FIN and see if the fin packet is ack.  Make sure a second fin is being generated.  Can you explain what you mean by "QUIT".  If a FIN has started, then the connection will be closed and the QUIT will not be sent.

    jdweng

    Monday, February 10, 2014 1:30 PM
  • QUIT - is a command that any SMTP server has to send before end of data sending

    Take a look at http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol

    look at the SMTP transport example section

    Also if SMTP 1 confirmed that it recieved email from SMTP 2 then SMTP 2 will not send the same email again as it has been marked as recieved, but microsoft outlook smtp server continue sending the same email again and again


    Assembler (.../z80/x86/x64...) the best language I've ever known


    • Edited by vozmen Monday, February 10, 2014 1:39 PM
    Monday, February 10, 2014 1:37 PM
  • You have two different network layers.  The SMTP is the application layer and TCP is the transport layer.  the TCP layer could be closing early before the SMTP application Layer sends the QUIT message.  I seen things like this happen frequently.  the easiest way of seening if the TCP has closed is to look for the FIN message in a sniffer.  IF the FIN is occuring before the SMTP QUIT is sent then you need to figure out why the FIN occured and which end of the conneciton sent the FIN.  There is a FIN and the a FIN ACK from the opposite end of the conneciton.  I suspect that the outlook smtp server is incorrectly sending the FIN.  but you application could be closing the TCP connection at the same time you send the QUIT and causing a race condition.  If you simultaneously send a QUIT and close a connection it will behave differently.

    Don't guess.  Use a sniffer a find out the root cause if the problem.


    jdweng

    Monday, February 10, 2014 1:52 PM
  • QUIT command sends only SMTP server that derives/sends emails, in our case QUIT should be sent by Microsoft Outlook SMTP server or it has to continue send emails (as there is only one email in our case than SMTP server has to send QUIT command and then terminate connection).

    But it does not send QUIT command and sometime it closes connection even before we responded with 250 OK.

    I do not know about FIN and FIN ACK but thank you anyway and I will try to look at it.

    Any other ideas for now?

    Thank you


    Assembler (.../z80/x86/x64...) the best language I've ever known


    • Edited by vozmen Monday, February 10, 2014 8:44 PM
    Monday, February 10, 2014 8:43 PM
  • Usually for http the last status is 200 done.  You may be getting some sort of time out.  Now we are dealing with 3 different Network layers.  TCP, HTTP, and SMTP.  You could check Control Panel, Administrative Tools : Event Viewer for error messages.

    With TCP you may want to turn on keep-alive.  Some server will time out when there are no TCP data for a period of time.  The TCP keep-alive on a client will send periodically an empty packet to the server so a server will not time out.  I suspect the server may be implimenting some sort of anti-spoofing algorithm and sending a 250 OK when an error is really occuring to fool hackers.  I think there is something wrong with your credentials.  I've never seen Outlook working with port 25 before.  Microsoft usually requires with email a secure connection and port 25 is not secure email.  Port 25 is the older port number for non secure email.  Outlook standards is to use SSL with a relay for connection on port number 587.


    jdweng

    Tuesday, February 11, 2014 1:53 AM
  • Lets clarify one thing, saying Outlook I do not mean Microsoft Outlook Email application or any other email application, I mean SMTP server wich dns name something like na01-by2-obe.outbound.protection.outlook.com which sends emails to the ourself written SMTP server through 25 port.

    Assembler (.../z80/x86/x64...) the best language I've ever known

    Tuesday, February 11, 2014 9:05 AM
  • Here is a last packet microsoft smtp (but it has part of data and not the last smtp protocol message):

      Frame: Number = 9451, Captured Frame Length = 60, MediaType = ETHERNET
    - Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[1C-6F-65-9E-DF-EF],SourceAddress:[90-F6-52-79-14-20]
      - DestinationAddress: 1C6F65 9EDFEF [1C-6F-65-9E-DF-EF]
         Rsv: (000111..)
         UL:  (......0.) Universally Administered Address
         IG:  (.......0) Individual address (unicast)
      - SourceAddress: 90F652 791420 [90-F6-52-79-14-20]
         Rsv: (100100..)
         UL:  (......0.) Universally Administered Address
         IG:  (.......0) Individual address (unicast)
        EthernetType: Internet IP (IPv4), 2048(0x800)
        UnknownData: Binary Large Object (6 Bytes)
    - Ipv4: Src = 207.46.163.237, Dest = 192.168.0.102, Next Protocol = TCP, Packet ID = 31195, Total IP Length = 40
      - Versions: IPv4, Internet Protocol; Header Length = 20
         Version:      (0100....) IPv4, Internet Protocol
         HeaderLength: (....0101) 20 bytes (0x5)
      - DifferentiatedServicesField: DSCP: 0, ECN: 0
         DSCP: (000000..) Differentiated services codepoint 0
         ECT:  (......0.) ECN-Capable Transport not set
         CE:   (.......0) ECN-CE not set
        TotalLength: 40 (0x28)
        Identification: 31195 (0x79DB)
      - FragmentFlags: 16384 (0x4000)
         Reserved: (0...............)
         DF:       (.1..............) Do not fragment
         MF:       (..0.............) This is the last fragment
         Offset:   (...0000000000000) 0
        TimeToLive: 114 (0x72)
        NextProtocol: TCP, 6(0x6)
        Checksum: 23242 (0x5ACA)
        SourceAddress: 207.46.163.237
        DestinationAddress: 192.168.0.102
    - Tcp: Flags=...A.R.., SrcPort=4884, DstPort=SMTP(25), PayloadLen=0, Seq=1356150847, Ack=1646909655, Win=0 (scale factor 0x8) = 0
        SrcPort: 4884
        DstPort: SMTP(25)
        SequenceNumber: 1356150847 (0x50D5383F)
        AcknowledgementNumber: 1646909655 (0x6229D8D7)
      - DataOffset: 80 (0x50)
         DataOffset: (0101....) 20 bytes
         Reserved:   (....000.)
         NS:         (.......0) Nonce Sum not significant
      - Flags: ...A.R..
         CWR:    (0.......) CWR not significant
         ECE:    (.0......) ECN-Echo not significant
         Urgent: (..0.....) Not Urgent Data
         Ack:    (...1....) Acknowledgement field significant
         Push:   (....0...) No Push Function
         Reset:  (.....1..) Reset
         Syn:    (......0.) Not Synchronize sequence numbers
         Fin:    (.......0) Not End of data
        Window: 0 (scale factor 0x8) = 0
        Checksum: 0xA463, Good
        UrgentPointer: 0 (0x0)


    Assembler (.../z80/x86/x64...) the best language I've ever known

    Tuesday, February 11, 2014 11:01 AM
  • I've programmed in all those assemblers and a few more.  Nothing in the code you posted clodes the connection.  So either the server is closing the connection because of an error or an exception is occuring in the client that is causing the conneciton to close.  I have debug a number of these cases myself and the easiest way is to find out why the TCP FIN occured.  Using a Sniffer is the easiest method.  You can use either wireshark or fiddler.  Keep track of the TCP packet number and keep track of the retries and the ACKs for each packets.  When a packet doesn't get ACK the sender will send the message multiple times (usually up to 3 times).  After 3 retries, the sender "may" issue a FIN to close the connections.

    Servers often will stop responding if the credentials are wrong to prevent hackers from penetrating the site.  So what may be happening is you are using the wrong credentials and the server stops responding.  Then after your client sends 3 retries the connection closes. 


    jdweng

    Tuesday, February 11, 2014 11:02 AM
  • there is not credentials as it is smtp server to smtp server talking, here is one more packet after which microsoft smtp closed connection:

      Frame: Number = 9514, Captured Frame Length = 60, MediaType = ETHERNET
    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[1C-6F-65-9E-DF-EF],SourceAddress:[90-F6-52-79-14-20]
    + Ipv4: Src = 207.46.163.235, Dest = 192.168.0.102, Next Protocol = TCP, Packet ID = 8865, Total IP Length = 40
    - Tcp: Flags=...A.R.., SrcPort=46887, DstPort=SMTP(25), PayloadLen=0, Seq=3462465315, Ack=771984880, Win=0 (scale factor 0x8) = 0
        SrcPort: 46887
        DstPort: SMTP(25)
        SequenceNumber: 3462465315 (0xCE610723)
        AcknowledgementNumber: 771984880 (0x2E038DF0)
      + DataOffset: 80 (0x50)
      - Flags: ...A.R..
         CWR:    (0.......) CWR not significant
         ECE:    (.0......) ECN-Echo not significant
         Urgent: (..0.....) Not Urgent Data
         Ack:    (...1....) Acknowledgement field significant
         Push:   (....0...) No Push Function
         Reset:  (.....1..) Reset
         Syn:    (......0.) Not Synchronize sequence numbers
         Fin:    (.......0) Not End of data
        Window: 0 (scale factor 0x8) = 0
        Checksum: 0x32EF, Good
        UrgentPointer: 0 (0x0)


    Assembler (.../z80/x86/x64...) the best language I've ever known

    Tuesday, February 11, 2014 11:15 AM
  • Why do you think the connection is closed?  Both of these messages are ACK by the IP address 207.46.163.237 (I think this is the server).

    First packet
    There is a lot of useful inforation in the packet info you sent.  This is an ACK packet to Frame 9451.   You server was listening on Port 25 and then created a 2nd port to handle the client messages on Port 4884.  Since it is an ACK packet there is no data in the packet.  This is not a FIN packet.  I can't tell for sure but it looks like the connection is still open.  I supect the server is 207.46.163.237 and the client is 192.168.0.192 since user websites are normally start with 192.  So this is an ACK from the server.

    Second packet.
    Another ACK from server.


    jdweng

    Tuesday, February 11, 2014 11:19 AM
  • "Why do you think the connection is closed? " because at this momment we are trying to continue read data or if we get from the remote smtp server "\r\n.\r\n" (end of data) we are trying to write 250 ok message queued... and we get Exception: An existing connection was forcibly closed by the remote host

    here is the sate of socket when the exception occures


    Assembler (.../z80/x86/x64...) the best language I've ever known

    Tuesday, February 11, 2014 11:29 AM
  • Here is another look at sniffer:

    5007 1:38:54 PM 2/11/2014 219.0550951 RapidVerifier.vshost.exe 192.168.0.102 207.46.163.212 TCP TCP:Flags=...A...., SrcPort=SMTP(25), DstPort=14548, PayloadLen=0, Seq=151222781, Ack=244005841, Win=256 (scale factor 0x8) = 65536 {TCP:495, IPv4:494}
    5008 1:38:55 PM 2/11/2014 219.1878099 RapidVerifier.vshost.exe 207.46.163.212 192.168.0.102 TCP TCP:[Continuation to #5000]Flags=...A...., SrcPort=14548, DstPort=SMTP(25), PayloadLen=1460, Seq=244005841 - 244007301, Ack=151222781, Win=255 (scale factor 0x8) = 65280 {TCP:495, IPv4:494}
    5009 1:38:55 PM 2/11/2014 219.1886496 RapidVerifier.vshost.exe 207.46.163.212 192.168.0.102 TCP TCP:[Continuation to #5000]Flags=...A...., SrcPort=14548, DstPort=SMTP(25), PayloadLen=1460, Seq=244007301 - 244008761, Ack=151222781, Win=255 (scale factor 0x8) = 65280 {TCP:495, IPv4:494}
    5010 1:38:55 PM 2/11/2014 219.1886496 RapidVerifier.vshost.exe 207.46.163.212 192.168.0.102 TCP TCP:[Continuation to #5000]Flags=...A...., SrcPort=14548, DstPort=SMTP(25), PayloadLen=1460, Seq=244008761 - 244010221, Ack=151222781, Win=255 (scale factor 0x8) = 65280 {TCP:495, IPv4:494}
    5011 1:38:55 PM 2/11/2014 219.1886496 RapidVerifier.vshost.exe 207.46.163.212 192.168.0.102 TCP TCP:[Continuation to #5000]Flags=...A...., SrcPort=14548, DstPort=SMTP(25), PayloadLen=1460, Seq=244010221 - 244011681, Ack=151222781, Win=255 (scale factor 0x8) = 65280 {TCP:495, IPv4:494}
    5012 1:38:55 PM 2/11/2014 219.1886496 RapidVerifier.vshost.exe 207.46.163.212 192.168.0.102 TCP TCP:[Continuation to #5000]Flags=...A...., SrcPort=14548, DstPort=SMTP(25), PayloadLen=1460, Seq=244011681 - 244013141, Ack=151222781, Win=255 (scale factor 0x8) = 65280 {TCP:495, IPv4:494}
    5013 1:38:55 PM 2/11/2014 219.1886496 RapidVerifier.vshost.exe 207.46.163.212 192.168.0.102 TCP TCP:[Continuation to #5000]Flags=...A...., SrcPort=14548, DstPort=SMTP(25), PayloadLen=1460, Seq=244013141 - 244014601, Ack=151222781, Win=255 (scale factor 0x8) = 65280 {TCP:495, IPv4:494}
    5014 1:38:55 PM 2/11/2014 219.1886496 RapidVerifier.vshost.exe 207.46.163.212 192.168.0.102 TCP TCP:[Continuation to #5000]Flags=...AP..., SrcPort=14548, DstPort=SMTP(25), PayloadLen=258, Seq=244014601 - 244014859, Ack=151222781, Win=255 (scale factor 0x8) = 65280 {TCP:495, IPv4:494}
    5015 1:38:55 PM 2/11/2014 219.1888246 RapidVerifier.vshost.exe 192.168.0.102 207.46.163.212 TCP TCP:Flags=...A...., SrcPort=SMTP(25), DstPort=14548, PayloadLen=0, Seq=151222781, Ack=244014859, Win=255 (scale factor 0x8) = 65280 {TCP:495, IPv4:494}
    5016 1:38:55 PM 2/11/2014 219.3174366 RapidVerifier.vshost.exe 207.46.163.212 192.168.0.102 TCP TCP:Flags=...A.R.., SrcPort=14548, DstPort=SMTP(25), PayloadLen=0, Seq=244014859, Ack=151222781, Win=0 (scale factor 0x8) = 0 {TCP:495, IPv4:494}

    at some points I see something is sent from our socket to the smtp server (but we do not send anything in our code)

    5007 1:38:54 PM  and 5015 1:38:55 PM and then connection is terminated by the romte server


    Assembler (.../z80/x86/x64...) the best language I've ever known

    Tuesday, February 11, 2014 11:44 AM
  • There are two main types of Internet messages : UDP and TCP.  Multicast is a Type of UDP which is a broadcast message and has an IP address from 224.0.0.0 to 239.0.0.0.  Broadcast means one PC can send a message and multiple receivers can listen to the message.  There is no ACK with UDP.

    TCP should never have a  broadcast message.  Check the Control Panel : Administrative tools : Event Viewer on both the client and server to see if there are any additional clues why the error occured.  The error seems to be occuring in yhour application and not from the server.  You may have firewall or virus protection program throwing the error.  You also may havve another application trying to use port 25 on the PC.  Shutdown the client and type in a cmd.exe "Netstrat -a" and check if there is any UDP applications using port 25


    jdweng

    Tuesday, February 11, 2014 11:44 AM
  • there is no other application that may use 25 port (we have tested on many PCs even without anything installed except our SMTP server)

    but I have noticed that last packet from our side has Reset:  (.....1..) Reset

    also next to last microsoft packet has another flag:

    Push:   (....1...) Push Function

    what does it mean and what can cause it?


    Assembler (.../z80/x86/x64...) the best language I've ever known



    • Edited by vozmen Tuesday, February 11, 2014 11:50 AM
    Tuesday, February 11, 2014 11:48 AM
  • The reset is probably occuring because of an exception in your software that is closing the connection.  Find the last time the client sent a message.  The problem is around the time the client last responded.  the last message from the server may of caused the exception.

    I think there are a lot of retries occuring since the sequence numbers from the server are not sequential.  find out where in the messages the server resends the same packet sequence number twice.

    Let me explain how TCP works.

    1) The server and client both have independant sequence numbers. 

    2) When a connection starts the sequence number on both client and server are set to 1.

    3) Every time a message is sent the sequence number is incremented and the receiving end of the connection acknowledges the message with the same sequence number.  The client could have a sequence number of 100 and the server 200.

    4) When a message is not acknowledged the message will be resent with the same sequence number.

    5) TCP packets are limited to 1500 bytes.  When messages are longer than 1500 bytes a continuation message will be sent.


    jdweng

    Tuesday, February 11, 2014 12:00 PM
  • I see the Reset occures on remote side as well without Reset on our side.

    Also, it is not clear for me why other SMTP servers like GMail and another Microsoft mail.live.com works well?


    Assembler (.../z80/x86/x64...) the best language I've ever known

    Tuesday, February 11, 2014 12:07 PM
  • Here is another communication list without RESET from our side but with from remote side:

    20440 1:49:24 PM 2/11/2014 848.8506105 RapidVerifier.vshost.exe JSD00001 207.46.163.153 SMTP SMTP:Rsp 220  localhost -- Fake proxy server, 36 bytes {TCP:1598, IPv4:1597}
    20445 1:49:24 PM 2/11/2014 849.0055034 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 SMTP SMTP:Cmd EHLO na01-bn1-obe.outbound.protection.outlook.com, 51 bytes {TCP:1598, IPv4:1597}
    20448 1:49:24 PM 2/11/2014 849.0532736 RapidVerifier.vshost.exe JSD00001 207.46.163.153 SMTP SMTP:Rsp 250 -localhost Hellow [na01-bn1-obe.outbound.protection.outlook.com], 150 bytes {TCP:1598, IPv4:1597}
    20458 1:49:25 PM 2/11/2014 849.2256168 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 SMTP SMTP:Cmd MAIL FROM:<> SIZE=30344 AUTH=<>, 33 bytes {TCP:1598, IPv4:1597}
    20459 1:49:25 PM 2/11/2014 849.2536742 RapidVerifier.vshost.exe JSD00001 207.46.163.153 SMTP SMTP:Rsp 250  OK, 8 bytes {TCP:1598, IPv4:1597}
    20462 1:49:25 PM 2/11/2014 849.4253092 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 SMTP SMTP:Cmd RCPT TO:<test@80.92.237.205>, 30 bytes {TCP:1598, IPv4:1597}
    20463 1:49:25 PM 2/11/2014 849.4546394 RapidVerifier.vshost.exe JSD00001 207.46.163.153 SMTP SMTP:Rsp 250  OK, 8 bytes {TCP:1598, IPv4:1597}
    20468 1:49:25 PM 2/11/2014 849.6286741 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 SMTP SMTP:Cmd DATA, Begins message composition {TCP:1598, IPv4:1597}
    20469 1:49:25 PM 2/11/2014 849.6566733 RapidVerifier.vshost.exe JSD00001 207.46.163.153 SMTP SMTP:Rsp 354  Start mail input; end with, 35 bytes {TCP:1598, IPv4:1597}
    20474 1:49:25 PM 2/11/2014 849.8290673 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 MIME MIME:Version =  1.0, multipart/report {TCP:1598, IPv4:1597}
    20475 1:49:25 PM 2/11/2014 849.8299205 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 TCP TCP:[Continuation to #20474]Flags=...A...., SrcPort=30267, DstPort=SMTP(25), PayloadLen=1460, Seq=1931559218 - 1931560678, Ack=2682120604, Win=255 (scale factor 0x8) = 65280 {TCP:1598, IPv4:1597}
    20476 1:49:25 PM 2/11/2014 849.8299874 RapidVerifier.vshost.exe JSD00001 207.46.163.153 TCP TCP:Flags=...A...., SrcPort=SMTP(25), DstPort=30267, PayloadLen=0, Seq=2682120604, Ack=1931560678, Win=256 (scale factor 0x8) = 65536 {TCP:1598, IPv4:1597}
    20481 1:49:25 PM 2/11/2014 849.9852907 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 TCP TCP:[Continuation to #20474]Flags=...A...., SrcPort=30267, DstPort=SMTP(25), PayloadLen=1460, Seq=1931560678 - 1931562138, Ack=2682120604, Win=255 (scale factor 0x8) = 65280 {TCP:1598, IPv4:1597}
    20482 1:49:25 PM 2/11/2014 849.9861282 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 TCP TCP:[Continuation to #20474]Flags=...A...., SrcPort=30267, DstPort=SMTP(25), PayloadLen=1460, Seq=1931562138 - 1931563598, Ack=2682120604, Win=255 (scale factor 0x8) = 65280 {TCP:1598, IPv4:1597}
    20483 1:49:25 PM 2/11/2014 849.9861282 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 TCP TCP:[Continuation to #20474]Flags=...A...., SrcPort=30267, DstPort=SMTP(25), PayloadLen=1460, Seq=1931563598 - 1931565058, Ack=2682120604, Win=255 (scale factor 0x8) = 65280 {TCP:1598, IPv4:1597}
    20484 1:49:25 PM 2/11/2014 849.9861282 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 TCP TCP:[Continuation to #20474]Flags=...A...., SrcPort=30267, DstPort=SMTP(25), PayloadLen=1460, Seq=1931565058 - 1931566518, Ack=2682120604, Win=255 (scale factor 0x8) = 65280 {TCP:1598, IPv4:1597}
    20485 1:49:25 PM 2/11/2014 849.9862533 RapidVerifier.vshost.exe JSD00001 207.46.163.153 TCP TCP:Flags=...A...., SrcPort=SMTP(25), DstPort=30267, PayloadLen=0, Seq=2682120604, Ack=1931566518, Win=256 (scale factor 0x8) = 65536 {TCP:1598, IPv4:1597}
    20488 1:49:26 PM 2/11/2014 850.1411652 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 TCP TCP:[Continuation to #20474]Flags=...A...., SrcPort=30267, DstPort=SMTP(25), PayloadLen=1460, Seq=1931566518 - 1931567978, Ack=2682120604, Win=255 (scale factor 0x8) = 65280 {TCP:1598, IPv4:1597}
    20489 1:49:26 PM 2/11/2014 850.1420007 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 TCP TCP:[Continuation to #20474]Flags=...A...., SrcPort=30267, DstPort=SMTP(25), PayloadLen=1460, Seq=1931567978 - 1931569438, Ack=2682120604, Win=255 (scale factor 0x8) = 65280 {TCP:1598, IPv4:1597}
    20490 1:49:26 PM 2/11/2014 850.1420007 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 TCP TCP:[Continuation to #20474]Flags=...A...., SrcPort=30267, DstPort=SMTP(25), PayloadLen=1460, Seq=1931569438 - 1931570898, Ack=2682120604, Win=255 (scale factor 0x8) = 65280 {TCP:1598, IPv4:1597}
    20491 1:49:26 PM 2/11/2014 850.1420007 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 TCP TCP:[Continuation to #20474]Flags=...A...., SrcPort=30267, DstPort=SMTP(25), PayloadLen=1460, Seq=1931570898 - 1931572358, Ack=2682120604, Win=255 (scale factor 0x8) = 65280 {TCP:1598, IPv4:1597}
    20492 1:49:26 PM 2/11/2014 850.1420007 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 TCP TCP:[Continuation to #20474]Flags=...A...., SrcPort=30267, DstPort=SMTP(25), PayloadLen=1460, Seq=1931572358 - 1931573818, Ack=2682120604, Win=255 (scale factor 0x8) = 65280 {TCP:1598, IPv4:1597}
    20493 1:49:26 PM 2/11/2014 850.1420007 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 TCP TCP:[Continuation to #20474]Flags=...A...., SrcPort=30267, DstPort=SMTP(25), PayloadLen=1460, Seq=1931573818 - 1931575278, Ack=2682120604, Win=255 (scale factor 0x8) = 65280 {TCP:1598, IPv4:1597}
    20494 1:49:26 PM 2/11/2014 850.1420007 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 TCP TCP:[Continuation to #20474]Flags=...AP..., SrcPort=30267, DstPort=SMTP(25), PayloadLen=196, Seq=1931575278 - 1931575474, Ack=2682120604, Win=255 (scale factor 0x8) = 65280 {TCP:1598, IPv4:1597}
    20495 1:49:26 PM 2/11/2014 850.1421802 RapidVerifier.vshost.exe JSD00001 207.46.163.153 TCP TCP:Flags=...A...., SrcPort=SMTP(25), DstPort=30267, PayloadLen=0, Seq=2682120604, Ack=1931575474, Win=255 (scale factor 0x8) = 65280 {TCP:1598, IPv4:1597}
    20499 1:49:26 PM 2/11/2014 850.2969751 RapidVerifier.vshost.exe 207.46.163.153 JSD00001 TCP TCP:Flags=...A.R.., SrcPort=30267, DstPort=SMTP(25), PayloadLen=0, Seq=1931575474, Ack=2682120604, Win=0 (scale factor 0x8) = 0 {TCP:1598, IPv4:1597}


    Assembler (.../z80/x86/x64...) the best language I've ever known

    Tuesday, February 11, 2014 12:09 PM
  • I don't see any TCP acknowledgement coming from the client.  The server is downloading an email and the client isn't responding.  The server probably after 3 to 5 seconds is going to start to resend the packets.  

    The SMTP is the application level and uses TCP as the transport level.  The trace looks like a summary trace because the sequence number is a range like 1931572358 - 1931573818.  It looks like the trace is the start of the sending of a long mail sequence and the server is sending the data in continuation blocks.


    jdweng

    Tuesday, February 11, 2014 12:33 PM
  • do you know - should we write "354 Start mail input; end with\r\n.\r\n"or "354 Start mail input; end with<CR><LF>.<CR><LF>" to the socket stream?

    Assembler (.../z80/x86/x64...) the best language I've ever known

    Tuesday, February 11, 2014 12:52 PM
  • going to check a few more times but it seems that sending "<CR><LF>.<CR><LF>" instead of "\r\n.\r\n" does solve the problem (in our case it was "\r\n." because we thought that last "\r\n" is added by sending message also enough)

    Assembler (.../z80/x86/x64...) the best language I've ever known


    • Edited by vozmen Tuesday, February 11, 2014 1:09 PM
    Tuesday, February 11, 2014 1:04 PM
  • When using c language "\n" get interpreted on different operating systems.  Windows uses 0x0D and 0x0A, Unix only uses 0x0D.  Since TCP was written based on Unix I would think you should only be sending 0x0D.   I would compare with what the working server are doing.

    I suspect your code is looking for both and CR and LF and is only getting the CR.  But not sure.  It looks like your code is gettting an exception just as the email message is being downloaded and not responding with the TCP ack.  My suspicions arre a firewall on the PC is blocking the port 4884 or 46687.  The initial transfer is being done on port 25, but when the email is being download another port number is being opened by the server.  You code may not handle the new port number.  Your listener must be able to handle multiple connections on different port numbers.  Another possiblility is your listener has a limit on the number of sockets that can get spawned.  When you call the listener constructor there is a number parameter which determines the max number of sockets.  You may need to increase this number.


    jdweng

    Tuesday, February 11, 2014 1:19 PM
  • "I suspect your code is looking for both and CR and LF and is only getting the CR" you are right we are looking for "\r\n.\r\n" as we have stated it in the message "354 Start mail input; end with<CR><LF>.<CR><LF>"

    so do you think we have look for "\r.\r" as well as for "\r\n.\r\n" ?


    Assembler (.../z80/x86/x64...) the best language I've ever known

    Tuesday, February 11, 2014 1:27 PM
  • Maybe just '\r'.  But I don't think this is the problem.  You application isn't opening up new port numbers that the server is requesting.  You application is acknoweldging the port 25 messages, but not acknowledging the port where the email messages are being sent.  Read the SMTP documentation to find out how to handle multiple port numbers.  There is a protocol where the server request the data transfer to be moved to auxilary ports and your code isn't following the protocol.  In one of the traces you posted there is the following message :

    "Fake proxy server"


    jdweng

    Tuesday, February 11, 2014 1:35 PM
  • Could you point me, please, where can I read for multiport smtp transfering?

    "In one of the traces you posted there is the following message : Fake proxy server" - this is answer from our smtp server, so this is ok, it could be any string.


    Assembler (.../z80/x86/x64...) the best language I've ever known

    Tuesday, February 11, 2014 1:39 PM
  • Look at the wiki article at the optional extension section with message 250.

    http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol


    jdweng

    Tuesday, February 11, 2014 1:43 PM
  • Thanks. And as I understand if we would replay with HELO it will mean that we do not support extensions as they are optional and all rmote smtp servers will have to use standard smtp protocl without extensions, right?

    Assembler (.../z80/x86/x64...) the best language I've ever known

    Tuesday, February 11, 2014 1:52 PM
  •  I really don't know all the details of your code.  Read the link on the Wiki page to RFC 1870 which gives all the details.  RFC specifications are not easy to read and I sometimes have to read a pragraph 20 to 30 times before I start to understand the requirements.  Then I usually still have to experiment to get the code working.  And I know what I'm doing.  I have never dealt with RFC 1870 before.

    jdweng

    Tuesday, February 11, 2014 2:00 PM
  • Look at RFC 1869

    http://tools.ietf.org/html/rfc1869


    jdweng

    Tuesday, February 11, 2014 2:23 PM
  • Hi all,

    we are still testing and will let know answer as soon as we get it

    Thank all.


    Assembler (.../z80/x86/x64...) the best language I've ever known

    Monday, March 10, 2014 8:47 AM
  • Hi All,

    Dont know how to mark it as answer but the answer is:

    "354 Start mail input; end with<CR><LF>.<CR><LF>"

    Thank you all


    Assembler (.../z80/x86/x64...) the best language I've ever known

    Wednesday, April 22, 2015 7:17 AM