Yep, IMail understood the 552 error when it was received out of
sequence from MS SMTP. So it appears that this might be a de facto
implementation, and servers that don't support it might be considered
to be functionally deficient, and hence the rarity of the issue.
Also take note that despite
Andy,
I actually just confirmed that this is an MS SMTP issue, or at least
related to how they handle this, and as always the logs are giving us
bad information.
I set an instance of MS SMTP up with a 2 KB limit for the message size,
and I then did a manual session with the server, attempting
Hi Matt:
I agree that the IIS log is omitting information
that we would like to see (e.g., it doesn't log the BDAT parameters for inbound
message - only for outgoing - and it doesn't log the mulit-line response to
an EHLO) - but I'd be surprised if the log "replaced" command values, e.g.,
Andy and Sandy,
I do see here that it is definitely improper to send a response during
a DATA or BDAT transfer (which is really, really stupid and speaks to
the age of the SMTP protocol).
Unfortunately MS SMTP doesn't log the DATA or BDAT command part of the
session, just the stuff before and
> The QUIT command is issued by the sending server of course. It then
> apparently waits for a 250 response and never gets one because MS
> SMTP has already given up on the message after the 552 error, and
> therefore the sending server just requeues the message and tries
> again on th
Hi,
sorry, I lost the original email. Somehow I
thought it saw a "BDAT" instead of "DATA" in the log - but I could be
mistaken. (Curious to see it
again.)
In any case, take a look at this:
http://freesoft.org/CIE/RFC/821/20.htm
This seems to imply, that the sender does not have to "l
Sandy,
One minute and 20 seconds after that log snippet showing the 552 error,
MS SMTP logs the following:
2005-07-09 05:11:09 204.0.181.214
mailhost1.neimanmarcus.com SMTPSVC1 VALHALLA 66.109.52.201 0 QUIT -
mailhost1.neimanmarcus.com 240 102953 105 4 102719 SMTP - -
The QUIT command is issu
> The error is sent however during the transfer of DATA, as soon as it
> is found that the message is too large. . .
Are you sure that that's what MS SMTP thinks it's doing? That's not
the behavior I observe in sending vastly oversize messages; MS SMTP
waits until the closing . to issue th
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
