search

trancos30 / subethasmtp

Automatically exported from code.google.com/p/subethasmtp
Other
1 stars 0 forks source link

done() handler called multiple times, once correctly, once AFTER the message has been reset #47

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Simply process an email

First invocation of done() handler:
Thread [org.subethamail.smtp.server.Session-/127.0.0.1:52903] (Suspended 
(breakpoint at line 41 in MessageHandlerImpl))  
    MessageHandlerImpl.done() line: 41  
    Session.endMessageHandler() line: 467   
    Session.resetMessageState() line: 451   
    DataCommand.execute(String, Session) line: 81   
    RequireTLSCommandWrapper.execute(String, Session) line: 27  
    CommandHandler.handleCommand(Session, String) line: 98  
    Session.runCommandLoop() line: 222  
    Session.run() line: 125 

Second invocation of done() handler:
Thread [org.subethamail.smtp.server.Session-/127.0.0.1:52903] (Suspended 
(breakpoint at line 41 in MessageHandlerImpl))  
    MessageHandlerImpl.done() line: 41  
    Session.endMessageHandler() line: 467   
    Session.run() line: 164 

Note: The second invocation is actually done on a NEW instance of the handler 
since a Session.resetMessageState() invocation happened in between the two 
calls above.

The second invocation is obviously unnecessary.

What version of the product are you using? On what operating system?
Mac OSX
subethasmtp v3.1.6

Original issue reported on code.google.com by gotnob...@gmail.com on 17 Oct 2011 at 9:49

GoogleCodeExporter commented 9 years ago 
As it is written in the done() javadoc, the done function is called even if 
none of the other MessageHandler methods are called. This is the correct 
behavior, otherwise proper cleanup were not always possible. The same situation 
also occurs when the client connects and then immediately quits, only done() is 
called. 
On the other hand this is indeed not really intuitive. As I see MessageHandler 
mostly corresponds to the "mail transaction" term of RFC 5321. The only 
difference is that a mail transaction only starts after the MAIL command, while 
MessageHandler is created immediately (on connection or after a successful DATA 
or RSET). If we strictly follow the mail transaction definition, then a 
MessageHandler instance should be created only after the MAIL command is 
received. In this case done() will not be called in the described situations, 
because no MessageHandler instance will exist.

Original comment by hontvari@flyordie.com on 18 Oct 2011 at 8:21

GoogleCodeExporter commented 9 years ago

Original comment by hontvari@flyordie.com on 19 Oct 2011 at 1:00

GoogleCodeExporter commented 9 years ago 
This is ripe for a unit test. ;-)

Original comment by latch...@gmail.com on 19 Oct 2011 at 1:11