Continue: Error msg with SMTP Email and SSL certificate - need any help please !

[Bruce]

>> Meanwhile they gave me a one time certificate for an "outside of process" usage and I could successfully retrieve the pending emails via Thunderbird portable.
So the certificate cannot be the prob, they use JKS, with NT I use PEM, Thunderbird uses PKCS (the last two I converted from the base JKS).

The certificate is not the problem. If SSL was not working you'd get nothing in the conversation.


>> The response mails are formal and of type "message disposition notification" (MDN) according to RFC 3798, thus:  content-type "multipart/report" with report-type "disposition-notification". Are ringing the bells maybe ?

clearly this is not a problem (not yet anyway), because there's no mail body being collected.

Cheers
Bruce

[tglomb]

meanwhile I got an answer of one of their proggies.. They set the zero bytes in the STAT and LIST answers by default, it has no meaning ATM.. Can this cause the break ?

They said also that the disconnect is originated within my program (NetDemo), also because I can retrieve the emails with Thunderbird without any probs. They have no idea why. Attached the NetDemo.log (shortened) of the affected part of the LIST command, maybe look aroung lines 359, 392, 393.
Do you have an idea ?

[attachment deleted by admin]

[tglomb]

Hello Bruce,
I think I found a possible problem in the NetEmailReceive class. First, I was misslead for a while because in _ProcessList() the Log gives out "NetEmailReceive._ProcessListAll". Here the "All" was confusing me. In my previous send Log this corresponds to line 356.

In my case:
At this time self.packet.bindata contains only a "+" and bindatalen equals to 1 (line 354). Inside _ProcessList() you call self._ProcessSplitReturned(splitStr) <> NET:RET_OKAY which results to false and so _ProcessRaiseError (SplitStr) is called (SplitStr is empty here). This is because inside _ProcessSplitReturned() you accept only "+OK" as a correct answer and thatswhy the return (with an empty error msg) and the following close.

So, now the question what's wrong.. Is "+" a possible correct answer to LIST and not only "+OK" or
did the developers of that POP3 server an error (but i.e. Thunderbird and Outlook can handle it) ?

Temporarely I changed the class code of _ProcessSplitReturned to
if self.packet.BinDataLen = 1
  if self.packet.binData [1] = '+'
    loc:ret = NET:RET_OKAY
  end
else
  if upper (self.packet.binData [1 : 3]) = '+OK'
    loc:ret = NET:RET_OKAY
  end
end
and the process goes on !
Now I can see the 2 emails in the Q and the first email also in the Log. But now it stops with
an error here: (line 523 in NetDemoLog3.txt)

if self.packet.BinDataLen < len (clip (p_Correct))
  self.ErrorTrap ('Too little data retured from ' & self._serverDesc & ' Server. Less than 3 bytes. State = ' &  self._state, 'NetEmailReceive._ProcessCopyBinData')
  self.close()
  return(1)

Please have a look at the attached Logs.. I have no idea whats going on.. maybe a similar prob like the above..
TIA, Thomas

[attachment deleted by admin]

[tglomb]

a desperate follow up..
after the described change to the class I can see the complete first email in the NetDll according to the Log. It breaks out now in the _ProcessCopyBinData method. Here also only a + is in bindata, but changing the p_Correct string to + makes no sense because then the second "Too little data.." with the missing CR Comes into play..
Anybody ?

[Bruce]

Hi Thomas,

unfortunately there's little I can do because without being able to duplicate the effect, it's impossible to trace the code and see how it's going.

Your best bet unfortunately is to understand the flow, and then figure out at what point the flow diverges from the expected, or desired. You might find that examining the flow from a more standard server might help you in determining the flow as well. ie if you connect to a server and see what it should be doing (as it goes through the code) - it's sometimes easier to spot the difference.

You seem to be on the right track - you've identified one part of the problem already, but I guess you just need to persevere.

Cheers
Bruce

[tglomb]

Ok Bruce..
a last question.. so far at least ;-)

There's a comment in the code I don't understand..
In _ProcessGetData() there is
if self._ProcessCopyBinData('+OK')                 ! Don't check for OK, it's checked in Do CopyBinData

I cannot find this Routine !?
TIA, Thomas

[tglomb]

Hello Bruce,
I think I found the problem.. Every answer of the server comes with 2 packets, first the + alone and after the OK..ect..
But the evaluation of the packet starts immediately after the first, the single + and so the Class breaks out (in _ProcessSplitReturned for LIST resp.  _ProcessCopyBinData for RETR).

So how can I "wait" for the complete answer ? This seems not so uncommon if Thunderbird/Outlook can handle this.
TIA, Thomas

[tglomb]

Problem solved !!!
They send the answers in two or more packets and thatswhy NetReceiveEmail gets confused. The answer to RETR 1 comes in 4 packets as +, all the text, '<13>', '<10>.<13,10>'. I remembered the code in my native NetSimple Progs within Process, case self.Packet.PacketType, of NET:SimpleDataPacket and I collect now everything (it's a little bit quick and dirty..) before letting Parent.Process() do the rest. The code I use now follows at the end for anyone who is interested (ATM I use the NetDemo example and the Loging refers to it).
Anyone is welcome to comment it or show me how to do it smother !
Thanks Bruce for your Patience here.
Thomas

! loc:PlusOnly is a bool(0), loc:SavePacket is a string( NET:MaxBinData)
log = clip(log) & '<13,10> <<<< -------------------------------------------------- new packet received -'
 
  if clip(self.packet.bindata) = '+'
    loc:PlusOnly= true
    log = clip(log) & '<13,10> + only - waiting for the rest !'
    return
  else
    if loc:PlusOnly
      loc:PlusOnly= false
      self.packet.bindata= '+' & clip(self.packet.bindata)
      self.packet.bindatalen+= 1
    end
  end
 
  if instring( '+OK Message follows', self.packet.bindata, 1, 1)
    if self.packet.bindata[ self.packet.bindatalen-4 : self.packet.bindatalen] <> '<13,10>.<13,10>' ! for security only
      loc:SavePacket= clip(self.packet.bindata)
      log = clip(log) & '<13,10> missing expected "end of email" - waiting for next packet (1) !'
      return
    end
  end
 
  if instring( '+OK Message follows', loc:SavePacket, 1, 1)
   
    log = clip(log) & '<13,10> ### |'
    loop k#= 1 to self.packet.bindatalen
      log = clip(log) & val( self.packet.bindata[ k#]) & '|'
    end!loop
    log = clip(log) & ' ###'
   
    loc:SavePacket= clip( loc:SavePacket) & clip(self.packet.bindata)
    k#= len( clip( loc:SavePacket))
    if loc:SavePacket[ k#-4 : k#] = '<13,10>.<13,10>'
      self.packet.bindata= clip( loc:SavePacket)
      self.packet.bindatalen= k#
      loc:SavePacket= ''
    else
      log = clip(log) & '<13,10> missing expected "end of email" - waiting for next packet (2) !'
      return
    end
    log = clip(log) & '<13,10> <<<< ' & clip(self.packet.bindata)
   
  else
    log = clip(log) & '<13,10> <<<< ' & clip(self.packet.bindata)
  end
 
  display(?log)