Bill,
The issue is that MS SMTP has a habit of sending back a 552 error while
the DATA transfer is still going on, and the sending server doesn't
notice the error and then just requeues the message. I did some
extensive research into this behavior and found that this was in fact
what was going on. See the following thread for the issue:
http://www.mail-archive.com/declude.junkmail@declude.com/msg25017.html
I then noticed yesterday a different form of behavior, at least in the
way that it was logged. Before MS SMTP was logging a BDAT with 552
error when the limit was reached even though the transfer wasn't BDAT.
Essentially the logging was not reflective of what was really going
on. Yesterday I noticed that the BDAT/552 logging stuff wasn't going
on anymore, instead it was logging QUIT after the 20 MB limit and then
a mysterious 25 minute gap and a timeout:
2005-08-04 01:42:58 216.224.43.19 mail.example.com
SMTPSVC1 VALHALLA 66.109.52.201 0 HELO - +mail.example.com
250 0 44 32 0 SMTP - -
2005-08-04 01:43:09 216.224.43.19 mail.example.com
SMTPSVC1 VALHALLA 66.109.52.201 0 MAIL - +FROM:<someone@example.com>
250 0 58 45 0 SMTP - -
2005-08-04 01:43:09 216.224.43.19 mail.example.com
SMTPSVC1 VALHALLA 66.109.52.201 0 RCPT - +TO:<recipient@example.com>
250 0 36 33 0 SMTP - -
---- 20 MB of data transfered and then MS SMTP quits the
reception of the data ---
2005-08-04 01:45:59 216.224.43.19 mail.example.com
SMTPSVC1 VALHALLA 66.109.52.201 0 QUIT - mail.example.com
240 213343 105 4 169734 SMTP - -
--- Strange 25 minute gap, no clue ---
2005-08-04 02:11:27 216.224.43.19 - SMTPSVC1 VALHALLA
66.109.52.201 0 TIMEOUT - - 121 321642712 220 4 116203 SMTP - -
2005-08-04 02:11:27 216.224.43.19 - SMTPSVC1 VALHALLA
66.109.52.201 0 QUIT - - 240 116203 220 4 116203 SMTP - -
If you are wondering what this behavior does when you have 4 messages
stuck in this redelivery loop, attached is a chart of my incoming
bandwidth from Tuesday and then Wednesday shown in hourly averages.
Based on my observations, there are terrible issues with messages that
are too large when HELO is used with MS SMTP. I have fixed this by
removing the limit from MS SMTP and if I want to apply one, I will do
it with IMail. It turns out that places like Yahoo are allowing
attachments up to 40 MB in size and not supporting ESMTP/EHLO, and
unfortunately people are using it to send huge attachments.
Matt
Bill Landry wrote:
----- Original Message -----
Sent:
Thursday, August 04, 2005 3:18 PM
Subject:
Re: [Declude.JunkMail] Spam box
One other note to add to this.
ORF plugs-into MS SMTP. I have unfortunately found that MS SMTP
doesn't appear to handle rejecting oversized attachments when sent with
HELO (not EHLO). When messages don't get rejected properly, they are
sent over and over again until they time out. I have a 20 MB limit
currently, but I found yesterday that there were at least 4 messages
being sent over and over and over again, all in excess of 20 MB.
That's a lot of bandwidth, in fact these four or so messages chewed up
about 4 times my normal bandwidth utilization. I also noted that this
issue occurred with another server using the same version of MS SMTP,
and others too of course.
This issue with MS SMTP is quite serious as it requires manual
intervention and lots of time to identify such messages, and therefore
it is also one of the reasons why I am moving to Postfix.
This would be true of any
mail server. If the remote server does not announce the size of the
message, which is only supported via ESMTP, then the receiving mail
server must receive the message up to the set limit before it can
reject the delivery.
Bill
--
=====================================================
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=====================================================
|
