[Declude.JunkMail] Somewhat OT: Sending server ignoring 552 SMTP error on large messages

[Matt]

I was hoping that someone could help me understand what is at issue with a problem that I have now faced twice in the past two months.  I know that it is related to either the sending server software (which is unknown) or MS SMTP which I use for my gateways. The issue is that I sometimes come across a server that insists on resending a message that is larger than I except on every one of it's queue runs until that message expires.   The first time that I saw this was with RCN, and now on Thursday I saw it again with one of Neiman Marcus' mail servers.  Their servers don't seem to bother with EHLO, which advertises the maximum size that we accept and is designed to stop the pointless sending of a message that is too large for our server to accept.  This will of course fall back to plain HELO which will start accepting the message, and then when it is found to be too large for our server, it will send back a 552 error, which is SMTP language for the message being too large.  The error is sent however during the transfer of DATA, as soon as it is found that the message is too large, but the sending server ignores the error and just keeps sending.  When the sending server is finished, it waits for a reply, and gets none because MS SMTP already sent the error, and so the sending server just simply requeues the message and tries again on the next spool run.  Since this only happens with messages that are too large for my gateways to accept, it takes an unbelievable amount of bandwidth.  For instance Neiman Marcus was retrying a 15 MB message once every 35 minutes for over 24 hours before I traced it down and blocked the sender which stopped the retries. The following is a log snippet from MS SMTP that shows the 552 error being ignored.  The long string of base64 data is supposed to be their response, but because it is base64 data, it shows that they are ignoring the error and just simply continuing to send the message. 2005-07-09 05:09:48 204.0.181.214 mailhost1.neimanmarcus.com SMTPSVC1 VALHALLA 66.109.52.201 0 BDAT - 67k1S91KS7n1CQ3Oo3JyHaaXl+uWY5759K/LsyzPGZ5NKS91rSztZW/U+9yrIqeBtVxnxf10Pgj4 qaxcavqd3JKZVjSaaJTCfkUls4I55NZfxP1S6e5g0K3dZYbWe9fdbgbQzuGZgQASG4JJ6HjoK4lk 3s0nTettX8vzPrMLiJyjzUlpZP8A4B8m+Lvt91b3WnpG32Q3InmT+9t6YP8ASt/xQbWysLq4e/V7 hldFgcEeXx16d+1KE5YeVGgoJyV9ddL/ANaHpOhzzjVqtWWiXrqfPtvoy3uo21j/AKRJNfXsdn5M ILO4dtvCjk11mn2cE0z6nbXU1ve2NsbnTZLclZorkH5SGU8dyDyQa+wy6vUVPmxUlGTso+d/8zy8 dGKV6ME359zlvFVxY2TQ2+nzLDb2tvFA6sV8syxvg89CucEZ/wAKr3Mz3V7cz6nEsV5DIpSSTH+k d+R/fzkt617sMbVrVoVFJXWj8uXTXzPNnhaUZupbfXVa3628rGhHq96Ip4nuXikuJFumYnAR+vA6 KAegGBXJ634nkMN0ySwusqkOyIv7vDdsDP0xXPKtXqTtPRJ62MIc2HlCLS26dPUtnxQNEN1F5+ZJ 4ZYpQuMZZ8kjI4J9q8S1DU4L0bTueVWcys7cYHTHetoOUZ+3pvTpp+HmEm67ftWmlqvM7/X/ABJD fuJoUkRUAZY2YHA3cAfTt0rx2TUfIY+WHcvgKCcg4PX/AArP2VepJWV3v6f8OTzU8N7l9kttT0uP xRrlpGq284.. 552 0 46 4 20812 SMTP - - The example from RCN a couple of months ago looked exactly the same, and although I was able to get in touch with one of their administrators, he didn't seem to understand the issue and I never found out what software was ignoring the 552 error.  I could also see the possibility that this is a problem with MS SMTP since this could be stopped dead if MS SMTP reported the error after the sending server issued a <CRLF>.<CRLF> to end the DATA transfer.  I also tried searching for this on Google and found one hint of Checkpoint firewalls not handling such things properly, but it wasn't detailed enough for me to determine if this was the same exact issue. So has anyone run into this with their own servers sending E-mail or receiving it, and if so, were you able to track the problem down to something specific. Thanks, Matt -- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =====================================================