Barney Desmond:
> * Noone's pointed out the your first packet capture also exhibits the
> same "missing data" problem. After the client sends RCPT TO and you
> respond with an Ok, the next thing it drops on the wire is "Received:
> from srv1.shoppingsquare.com.au" in frame 12. I'm not that confident in
No. The client sends both RCPT TO and DATA in one TCP segment.
This is legitimate use of the PIPELINING option (another feature
that has troubled firewalls from people who can't be bothered to
learn how protocols work).
Wietse
03:10:20.185623 117.58.250.202.60666 > 202.76.131.108.25: P 105:149(44) ack 218
win 54 <nop,nop,timestamp 1033756020 180933> (DF)
IP_HDR=20 IP_OPT=0 TCP_HDR=20 TCP_OPT=12 DATA=44 FLAGS=PUSH ACK
IP_HDR 45 00 00 60 b9 0b 40 00 36 06
vhl tos len len id id off off ttl pro
IP_HDR cd ce 75 3a fa ca ca 4c 83 6c
sum sum src src src src dst dst dst dst
TCP_HDR ec fa 00 19 f7 69 65 f9 86 8a
src src dst dst seq seq seq seq ack ack
TCP_HDR c8 ec 80 18 00 36 49 a4 00 00
ack ack off flg win win sum sum urp urp
TCP_OPT 01 01 08 0a 3d 9d dd 74 00 02
opt opt opt opt opt opt opt opt opt opt
TCP_OPT c2 c5
opt opt
DATA 52 43 50 54 20 54 6f 3a 3c XX
R C P T T o : < X RCPT To:<X
DATA XX XX XX XX 6d 69 6c 6c 65 72
X X X X m i l l e r XXXXmiller
DATA 40 77 65 62 67 61 74 65 2e 6e
@ w e b g a t e . n @webgate.n
DATA 65 74 2e 61 75 3e 0d 0a 44 41
e t . a u > ^M ^J D A et.au>..DA
DATA 54 41 0d 0a
T A ^M ^J TA..
