On Tue, 2003-07-22 at 19:22, Philip Hazel wrote:
> On 22 Jul 2003, Onno Benschop wrote:
>
> > I had rather hoped to avoid sniffing the network to see what is
> > happening, but if that is what is recommended, I'm happy to do so.
>
> I think that's what you'll have to do.
Right, so, now that I've done that, I'm still no wiser...
I've captured all the packets that do the transfer, and basically, the
message gets sent to the other side with the following transcript
(please note that I'm typing this in, because I can't actually extract
the session from the packets - anyone know how to do this in ethereal?)
The > denotes me, the < denotes them:
<220 {theirHostName} ESMTP Exim 4.10 Wed, 23 Jul 2003 11:03:25 + 0800\r\n
>EHLO {myHostName}\r\n
<250-{theirHostName} Hello {myHostName} [{myHostIP}]\r\n
<250-SIZE 52428800\r\n
<250-PIPELINING\r\n
<250-AUTH CRAM-MD5\r\n
<250 HELP\r\n
>MAIL FROM:<myaddress@mydomain> SIZE=2872\r\n
>RCPT TO: <theiraddress@theirdomain>\r\n
>DATA\r\n
<250 OK\r\n
<250 Accepted\r\n
<354 Enter message, ending with "." on a line by itself\r\n
>{the message}
>\r\n
>\r\n
>.\r\n
After some time:
<421 {theirHostName} SMTP incoming data timeout - closing connection\r\n
>QUIT
To spice things up, the message then goes onto their secondary MX, which
then ultimately responds with: 503 Error: neet RCPT command\r\n
(Of course that RCPT does get sent in the same fashion as it does
above...)
(Lets not try to fix the secondary MX at this stage, but attempt to fix
the first one, given that us and them can in fact change our own
settings, where the secondary MX, this is not true...)
So, any bright ideas?
Onno Benschop
Connected via Optus B3 from S33:37'33" - E115:07'30" (Dunsborough, WA)
--
()/)/)() ..ASCII for Onno..
|>>? ..EBCDIC for Onno..
--- -. -. --- ..Morse for Onno..
Proudly supported by Skipper Trucks, Highway1, Concept AV, Sony Central, Dalcon
ITmaze - ABN: 56 178 057 063 - ph: 04 1219 8888 - onno at itmaze dot com dot au
