Please note the attached E-mail below from when I first brought up this
topic.
Here's the issue. Between various products not being able to
understand 552 errors when they are sent during a DATA transmission,
and IMail not fully supporting RFC 1870 (SMTP Service Extension for
Message Size Declaration), this is causing repeated retransmission of
massively large E-mails. I have tried many different tricks between
three different products in order to try to get this to work without
issues and none of the workarounds will work. The primary issues are
with IMail however, and this glaring oversight.
RFC 1870 establishes that not only should a server using EHLO state the
SIZE property as being supported, but it should also append the SIZE
property to the MAIL FROM command when making a connection like so:
MAIL FROM:<[EMAIL PROTECTED]>+SIZE=15079
IMail doesn't do this. The result is that despite the fact that a
receiving server supports EHLO and advertises a size limit, and would
respond appropriately to the above command with an immediate 552 error
causing the E-mail to be bounced without wasting bandwidth, IMail just
sends the E-mail regardless of size, and it will miss the 552 error
unless the receiving server waits for the entire message to be sent,
even if it is over it's size limit. Issues with missing the 552 error
are not uncommon at all, in fact it is clear that both MS SMTP/Exchange
as well as SmarterMail will send the 552 error back during the
transmission of DATA, and IMail misses this. So what happens then?
IMail requeues the message and attempts to deliver it over and over and
over again until your queue retry limit is reached. A single 50 MB
message set to retry every 30 minutes for 48 hours would take up 4.8 GB
of bandwidth when stuck in this retry loop. I pay for bandwidth like
most of us, and this can be very expensive, especially when this
becomes an almost daily occurrence for a server like mine.
I have tried to block this at my gateway using an RFC 1870 compliant
server, MS SMTP, however there are other servers out there that don't
support EHLO, and don't understand an intra-DATA 552 error, and they
will stick themselves in a loop. The only way to handle this properly
seems to be within my own network, but I can't get every part of it to
work due to non-compliance. In this case, it appears that IMail is
what is non-compliant in regard to not supporting the SIZE property,
and also in not understanding the intra-DATA 552 errors.
Is Ipswitch going to fix this?
Matt
Matt wrote:
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]>
20050810 121147 127.0.0.1 SMTP (2725dc7000feb357) 250 OK
<[EMAIL PROTECTED]>
Sender ok
20050810 121147 127.0.0.1 SMTP (2725dc7000feb357) >RCPT
To:<[EMAIL PROTECTED]>
20050810 121147 127.0.0.1 SMTP (2725dc7000feb357) 250 OK
<[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
|
