Hello,
While troubleshooting my mail configuration, I found what I beleive to be bugs
at the link, session and application layers. Relevant to this list is the
application layer. I am trying to use Exim4 in STMP client mode.
After receiving "535 authentication failed (#5.7.1)" from the server, my
computer reponds with: "MAIL FROM: <nephill#X#icrossroads.com> SIZE=1633\r\n"
(Because Email addresses are supposed to be kept confidential, I will replace
'@' with #X#)
From my notes:
Exim4 (my computer) Asks for "AUTH CRAM-MD5", which ultimately fails (code
535)
. Seemingly disregarding the result, Exim goes ahead with:
MAIL FROM:<nephill#X#icrossroads.com> SIZE=1636\r\n
RCPT TO:<ljphillips#X#myrealbox.com>\r\n
DATA\r\n
(As an asside, wireshark was not able to parse this properly)
STMP server responds with
250 OK\r\n
My computer, for some unknown reason send out an empty TCP packet
acknowleding
a future TCP packet. Wiresharks' SEQ/ACK analysis says it is a response to the
previous packet, but my interpretation is borne out by what happens next:
Exim4 sends: QUIT\r\n
My computer sends another empty TCP packet (FIN, ACK)
STMP send the previously acknowledged packet:
221 pteradon.tera-byte.com\r\n
My computer now bails by sending another TCP (RST) packet.
STMP server acknowledges The RST with a TCP (FIN, ACK)
My computer resends the (RST) packet.
The packets (Frames) appear to be out of order (time-wise)!
Screenshot:
http://www.icrossroads.com/~nephill/wireshard_email.png
Frame 76 appears to acknowledge frame 79
10 seconds later, my computer tries again with the CRAM-MD5.
This time, after the authentication failure, it sends:
MAIL FROM:<> SIZE=2665\r\n
Then proceeds to send the failure message to the STMP server.
---
I later determined that the out-of order Frames were localized to my setup on
the one computer (could be a driver conflict or something (Did not happen
with a live CD on the same hardware))
I was able to reproduce the problem on a second computer with the same
software, but different hardware.
The packets/frames in question have been saved to a file:
http://www.icrossroads.com/~nephill/test_exim4_stmp.libpcap
(I used wireshark, but gather any libpcap based packet sniffer may be able to
read it.) (I deliberately used the wrong password for the capture in case one
of you can crack CRAM-MD5)
Software:
Debian Etch system (x86, 32bit)
exim4 4.63-17
exim4-config 4.63-17 (debian specific)
mutt 1.5.13-1.1e
wireshark 0.99.4-5.et
I am using the Maildir Option, incase that affects things.
Regards,
James Phillips
%22%20from%20the%20server,%20my%20%0A>%20computer%20reponds%20with:%20%22MAIL%20FROM:%20<nephill#X#icrossroads.com>%20SIZE=1633%5Cr%5Cn%22%0A>%20%0A>%20(Because%20Email%20addresses%20are%20supposed%20to%20be%20kept%20confidential,%20I%20will%20replace%20%0A>%20'@'%20with%20#X#)%0A>%20%0A>%20From%20my%20notes:%0A>%20Exim4%20(my%20computer)%20Asks%20for%20%22AUTH%20CRAM-MD5%22,%20which%20ultimately%20fails%20(code%20%0A>%20535)%0A>%20.%20Seemingly%20disregarding%20the%20result,%20Exim%20goes%20ahead%20with:%0A>%20MAIL%20FROM:<nephill#X#icrossroads.com>%20SIZE=1636%5Cr%5Cn%0A>%20RCPT%20TO:<ljphillips#X#myrealbox.com>%5Cr%5Cn%0A>%20DATA%5Cr%5Cn%0A>%20%20(As%20an%20asside,%20wireshark%20was%20not%20able%20to%20parse%20this%20properly)%0A>%20STMP%20server%20responds%20with%0A>%20250%20OK%5Cr%5Cn%0A>%20%20My%20computer,%20for%20some%20unknown%20reason%20send%20out%20an%20empty%20TCP%20packet%20%0A>%20acknowleding%0A>%20a%20future%20TCP%20packet.%20Wiresharks'%20SEQ/ACK%20analysis%20says%20it%20is%20a%20response%20to%20the%0A>%20previous%20packet,%20but%20my%20interpretation%20is%20borne%20out%20by%20what%20happens%20next:%0A>%20Exim4%20sends:%20QUIT%5Cr%5Cn%0A>%20%20My%20computer%20sends%20another%20empty%20TCP%20packet%20(FIN,%20ACK)%0A>%20STMP%20send%20the%20previously%20acknowledged%20packet:%0A>%20221%20pteradon.tera-byte.com%5Cr%5Cn%0A>%20%20My%20computer%20now%20bails%20by%20sending%20another%20TCP%20(RST)%20packet.%0A>%20STMP%20server%20acknowledges%20The%20RST%20with%20a%20TCP%20(FIN,%20ACK)%0A>%20%20My%20computer%20resends%20the%20(RST)%20packet.%0A>%20%0A>%20%20The%20packets%20(Frames)%20appear%20to%20be%20out%20of%20order%20(time-wise)!%0A>%20Screenshot:%20http://www.icrossroads.com/~nephill/wireshard_email.png%0A>%20Frame%2076%20appears%20to%20acknowledge%20frame%2079%0A>%20%0A>%2010%20seconds%20later,%20my%20computer%20tries%20again%20with%20the%20CRAM-MD5.%0A>%20This%20time,%20after%20the%20authentication%20failure,%20it%20sends:%0A>%20MAIL%20FROM:<>%20SIZE=2665%5Cr%5Cn%0A>%20%0A>%20Then%20proceeds%20to%20send%20the%20failure%20message%20to%20the%20STMP%20server.%0A>%20---%0A>%20I%20later%20determined%20that%20the%20out-of%20order%20Frames%20were%20localized%20to%20my%20setup%20on%20%0A>%20the%20one%20computer%20(could%20be%20a%20driver%20conflict%20or%20something%20(Did%20not%20happen%20%0A>%20with%20a%20live%20CD%20on%20the%20same%20hardware))%20%0A>%20%0A>%20I%20was%20able%20to%20reproduce%20the%20problem%20on%20a%20second%20computer%20with%20the%20same%20%0A>%20software,%20but%20different%20hardware.%0A>%20The%20packets/frames%20in%20question%20have%20been%20saved%20to%20a%20file:%0A>%20http://www.icrossroads.com/~nephill/test_exim4_stmp.libpcap%0A>%20(I%20used%20wireshark,%20but%20gather%20any%20libpcap%20based%20packet%20sniffer%20may%20be%20able%20to%20%0A>%20read%20it.)%20(I%20deliberately%20used%20the%20wrong%20password%20for%20the%20capture%20in%20case%20one%20%0A>%20of%20you%20can%20crack%20CRAM-MD5)%0A>%20%0A>%20%0A>%20I%20am%20using%20the%20Maildir%20Option,%20incase%20that%20affects%20things.%0A>%20%0A>%20Regards,%0A>%20%0A>%20James%20Phillips%0A>%20%0A>%20 "Répondre à ce message")
