But should Imail be sending the message at all?  I think that is the
OP's concern.  If the remote server responds to EHLO with "250-SIZE
20971520", should Imail recognize that the message it is trying to send
is too large and shouldn't even be attempted?

________________________________

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric Shanbrom
Sent: Thursday, August 11, 2005 5:12 PM
To: [email protected]
Subject: Re: [IMail Forum] IMail ignores EHLO message size limits???
Bad...


The way I see the log is the receiving server is not letting IMail know
the message is too big. It should send a 552 error code rather then just
drop the connection. By just dropping the connection IMail will look at
it as a broken connection and requeue the message... So in a nutshell,
it looks like the receiving server is broken
 
Eric S

        ----- Original Message ----- 
        From: Matt <mailto:[EMAIL PROTECTED]>  
        To: [email protected] 
        Sent: Thursday, August 11, 2005 4:33 PM
        Subject: [IMail Forum] IMail ignores EHLO message size limits???
Bad...

        While looking into why my outbound bandwidth was spiking every
15 minutes I found that there was a 40 MB message in the spool that was
responsible for this.  It was being resent every 15 minutes and taking
up gobs of bandwidth.
        
        The server that it was sending to supports EHLO, in fact it is
also my own server.  Here's what the session states after an EHLO
command:
        

                EHLO mail.mailpure.com
                250-heimdall Hello [66.109.52.12]
                250-SIZE 20971520
                250-AUTH LOGIN CRAM-MD5
                250 OK
                

        My understanding of ESMTP is that if the message is more than
20,971,520 bytes as indicated in the SIZE response, then it should not
be sent.  This message was more than 41,874,785 bytes and it was sent
regardless.  Not such a big deal on it's own, but IMail never figures
out that the message is oversized even after sending it, and it
therefore just requeues the message and tries sending it until your
server's retry limit has been reached.  I had also verified the same
thing a few weeks ago with yet another server (running MS SMTP) where
IMail would use EHLO but ignore the size limit and send regardless.
Here's the IMail log snippet.
        

                20050810 121146 127.0.0.1       SMTP (2725dc7000feb357)
processing F:\\Q2725dc7000feb357.SMD
                20050810 121146 127.0.0.1       SMTP (2725dc7000feb357)
Trying recip.example.com (0)
                20050810 121146 127.0.0.1       SMTP (2725dc7000feb357)
Connect recip.example.com [66.109.52.200:25] (1)
                20050810 121146 127.0.0.1       SMTP (2725dc7000feb357)
220 mail.mailpure.com
                20050810 121146 127.0.0.1       SMTP (2725dc7000feb357)
>EHLO mail.mailpure.com
                20050810 121147 127.0.0.1       SMTP (2725dc7000feb357)
250-heimdall Hello [66.109.52.12]
                20050810 121147 127.0.0.1       SMTP (2725dc7000feb357)
250-SIZE 20971520
                20050810 121147 127.0.0.1       SMTP (2725dc7000feb357)
250-AUTH LOGIN CRAM-MD5
                20050810 121147 127.0.0.1       SMTP (2725dc7000feb357)
250 OK
                20050810 121147 127.0.0.1       SMTP (2725dc7000feb357)
>MAIL FROM:<[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> 
                20050810 121147 127.0.0.1       SMTP (2725dc7000feb357)
250 OK <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]>
Sender ok
                20050810 121147 127.0.0.1       SMTP (2725dc7000feb357)
>RCPT To:<[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> 
                20050810 121147 127.0.0.1       SMTP (2725dc7000feb357)
250 OK <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]>  Recipient
ok
                20050810 121147 127.0.0.1       SMTP (2725dc7000feb357)
>DATA
                20050810 121147 127.0.0.1       SMTP (2725dc7000feb357)
354 Start mail input; end with <CRLF>.<CRLF>
                20050810 121156 127.0.0.1       SMTP (2725dc7000feb357)
>.
                20050810 121156 127.0.0.1       SMTP (2725dc7000feb357)
rl-recv: connection reset
                20050810 121156 127.0.0.1       SMTP (2725dc7000feb357) 
                20050810 121156 127.0.0.1       SMTP (2725dc7000feb357)
SMTP_DELIV_FAILED
                20050810 121156 127.0.0.1       SMTP (2725dc7000feb357)
>QUIT
                20050810 121156 127.0.0.1       SMTP (2725dc7000feb357)
rl-recv: connection reset
                20050810 121156 127.0.0.1       SMTP (2725dc7000feb357) 
                20050810 121156 127.0.0.1       SMTP (2725dc7000feb357)
requeuing F:\\Q2725dc7000feb357.SMD R0 T1
                20050810 121156 127.0.0.1       SMTP (2725dc7000feb357)
finished F:\\Q2725dc7000feb357.SMD status=3
                

        So what is going on here?  Is IMail broken?
        
        This issue can cause major problems as MS SMTP (used by Exchange
servers) has an issue where it will return a 552 error in the middle of
the DATA command instead of waiting for it to finish the transmission,
and some server's don't know to listen for one in the middle of a
transfer.  So if a server is going to send oversized messages, it can
cause big bandwidth problems when they are tried over and over again.
        
        FYI, I am using 8.15 HF1 currently.
        
        Matt
        
        
        
        
        
        
        
        


To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/

Reply via email to