* This is the modus mailing list *
Thanks Del, this is the route that we were looking at.
What is weird though is that we see several off these in a row if
several messages are in the queue.
However, on tests I sent over 100,000 emails through with no issues
(well, other than a huge increase in queues on our internal email
infrastructure).
In addition I left my hotmail address in when running the initial test
and flooded that mailbox as well as getting 14,900+ bounce messages due
to the mailbox being full.
---
If you get cheated by the Better Business Bureau, who do you complain
to?
(--------------------------------) {((((((
( Suneel Jhangiani ) /_ _ )
( Technical Director ) ( . . )
( Inter-Computer Technology Ltd. ) ( / )
(----------------------------------oOOo------------oOOo----)
( 40 James Street Tel: +44 (0) 20 7486 9601 )
( London W1U 1EU Fax: +44 (0) 7050 678 978 )
( United Kingdom Email: [EMAIL PROTECTED] )
( Website: http://www.inctech.com )
(----------------------------------------------------------)
-----Original Message-----
From: Del Hines [mailto:[EMAIL PROTECTED]
Sent: 19 January 2004 15:10
To: [EMAIL PROTECTED]
Subject: [Modus] {OT} Small business Server Delays
* This is the modus mailing list *
Hi Suneel,
Regarding your log snippet, I've seen this behavior before with a
specific client application sending to our server. Our issue still
remains unresolved although I believe it to be a bug in the sending
application.
However, the following info may help with your troubleshooting. I
recommend watching the SMTP exchange with a packet sniffer. Even if
some data comes through after the DATA command, if the TCP connection
terminates before receiving the <CRLF>.<CRLF>, modusmail will record a
log exactly like your snippet.
In our case, the captured TCP packets showed the sending client would
actually send about 2KB (attachments) after the DATA command but would
terminate the TCP connection prior to sending _all_ of the data
including the <CRLF>.<CRLF>.
In your case, I wouldn't dismiss seemingly unrelated causes such as a
problematic NIC or overloaded NAT firewall or something.
Hope this helps,
- Del
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
> Of Suneel Jhangiani
> Sent: Monday, January 19, 2004 7:12 AM
> To: [EMAIL PROTECTED]
> Subject: [Modus] {OT} Small business Server Delays
>
> * This is the modus mailing list *
>
> Ok, here is a log snippet, however what you should be aware off is
that
> the OPR log was set with all logging options on including Received and
> Transmitted Data.
>
> ***** Our Modus Log:
>
>
> ---- SMTPRS log entry made at 01/19/2004 12:55:33
> Incoming SMTP call from 212.58.150.133 at 12:55:27.
> <<< 220 mail-gw2.inctech.com ModusMail ESMTP Receiver Version
2.0.241.0
> Ready
> >>> EHLO sbs.grierolubi.co.uk
> <<< 250-mail-gw2.inctech.com
> 250-SIZE 0
> 250-ETRN
> 250-ENHANCEDSTATUSCODES
> 250-X-IMS 5 40
> 250-DSN
> 250-VRFY
> 250 8BITMIME
> >>> MAIL FROM:<[EMAIL PROTECTED]>
> <<< 250 2.0.0 [EMAIL PROTECTED] OK
> >>> RCPT TO:<[EMAIL PROTECTED]>
> <<< 250 2.0.0 [EMAIL PROTECTED] OK
> >>> DATA
> <<< 354 Ready for data
> Incoming SMTP call from 212.58.150.133 completed at 12:55:33.
>
>
>
> As the log shows, no DATA was actually transmitted....
>
>
>
> **
> To unsubscribe, send an Email to: [EMAIL PROTECTED]
> with the word "UNSUBSCRIBE" in the body or subject line.
**
To unsubscribe, send an Email to: [EMAIL PROTECTED]
with the word "UNSUBSCRIBE" in the body or subject line.
**
To unsubscribe, send an Email to: [EMAIL PROTECTED]
with the word "UNSUBSCRIBE" in the body or subject line.
