CR CR . CR CR and Exchange
Rob McMahon
I've come back after Christmas to find a stuck message on its way to
Exchange, holding up the queue. The Exchange server had replied
421 5.5.2 Syntax error (invalid DATA termination)\r\n
and the message was held with
xxx@yyy... Deferred: 421 5.5.2 Syntax error (invalid DATA termination)\n
Effectively blocking all further mail to that server, leaving ~1000
messages in the queue.
Now Microsoft say that means
"SMTP filter encountered an invalid DATA terminator
Some character combinations in DATA may pose a security risk. The
connection has been terminated.
SMTP filter event
Invalid DATA termination"
And it appears the cause was the occurrence of
CR CR . CR CR
in the message. It appears that Exchange is being overly picky (and a
421 response seems completely wrong, but I see this has already been
discussed). On the other hand, RFC8281 says
"2.3.7 Lines
...
In addition, the appearance of "bare" "CR" or "LF" characters in text
(i.e., either without the other) has a long history of causing
problems in mail implementations and applications that use the mail
system as a tool. SMTP client implementations MUST NOT transmit
these characters except when they are intended as line terminators
and then MUST, as indicated above, transmit them only as a <CRLF>
sequence."
So it appears sendmail (8.13.8) isn't conforming to the RFC, either. So
1) Does anyone know how to get Exchange to be less picky ?
2) Is there a way to stop sendmail sending bare CR or LF characters ?
(I don't mind setting up a special mailer for this service).
3) Any other comments / advice ?
Cheers,
Rob
Kari Hurtta
> Hi
>
> I've come back after Christmas to find a stuck message on its way to
> Exchange, holding up the queue. The Exchange server had replied
>
> 421 5.5.2 Syntax error (invalid DATA termination)\r\n
>
> and the message was held with
>
> xxx@yyy... Deferred: 421 5.5.2 Syntax error (invalid DATA termination)\n
>
> Effectively blocking all further mail to that server, leaving ~1000
> messages in the queue.
>
> Now Microsoft say that means
>
> "SMTP filter encountered an invalid DATA terminator
> Some character combinations in DATA may pose a security risk. The
> connection has been terminated.
> SMTP filter event
> Invalid DATA termination"
>
> And it appears the cause was the occurrence of
>
> CR CR . CR CR
>
> in the message. It appears that Exchange is being overly picky (and a
> 421 response seems completely wrong, but I see this has already been
> discussed). On the other hand, RFC8281 says
If smtp server guess that there is data syncronazation problem, then
disconnection is only possibility. And 421 means that server will close
connection. Only other code which imply closing of connection is 221
and this is response for QUIT. ( 521 seems not exists )
> "2.3.7 Lines
> ...
> In addition, the appearance of "bare" "CR" or "LF" characters in text
> (i.e., either without the other) has a long history of causing
> problems in mail implementations and applications that use the mail
> system as a tool. SMTP client implementations MUST NOT transmit
> these characters except when they are intended as line terminators
> and then MUST, as indicated above, transmit them only as a <CRLF>
> sequence."
>
> So it appears sendmail (8.13.8) isn't conforming to the RFC, either. So
Yes.
> 1) Does anyone know how to get Exchange to be less picky ?
I'm afrain that threating
CR . CR
and
LF . LF
as error is only safe possibility, because it is possibility
that some mailers (for example sendmail in later case) may treat
it as end of DATA although it is not.
> 2) Is there a way to stop sendmail sending bare CR or LF characters ?
> (I don't mind setting up a special mailer for this service).
Seems not. (It seems to have possible to disable LF . LF to
be treated as end of DATA, but that is different issue -- ie.
EF_NL_NOT_EOL on e->e_flags on collect() -- and also I do not
found where that can be set ....)
> 3) Any other comments / advice ?
>
> Cheers,
>
> Rob
/ Kari Hurtta
Kari Hurtta
in comp.mail.sendmail:
> Rob McMahon <Rob.M...@warwick.ac.uk> writes in comp.mail.sendmail:
>
> > Hi
> >
> > I've come back after Christmas to find a stuck message on its way to
> > Exchange, holding up the queue. The Exchange server had replied
> >
> > 421 5.5.2 Syntax error (invalid DATA termination)\r\n
> >
> > and the message was held with
> >
> > xxx@yyy... Deferred: 421 5.5.2 Syntax error (invalid DATA termination)\n
> >
> > Effectively blocking all further mail to that server, leaving ~1000
> > messages in the queue.
> >
> > Now Microsoft say that means
> >
> > "SMTP filter encountered an invalid DATA terminator
> > Some character combinations in DATA may pose a security risk. The
> > connection has been terminated.
> > SMTP filter event
> > Invalid DATA termination"
> >
> > And it appears the cause was the occurrence of
> >
> > CR CR . CR CR
> >
> > in the message. It appears that Exchange is being overly picky (and a
> > 421 response seems completely wrong, but I see this has already been
> > discussed). On the other hand, RFC8281 says
>
> If smtp server guess that there is data syncronazation problem, then
> disconnection is only possibility. And 421 means that server will close
> connection. Only other code which imply closing of connection is 221
> and this is response for QUIT. ( 521 seems not exists )
Correction: 521 exists on RFC 1846 ( Experimental )
"This memo defines a new Simple Mail Transfer Protocol (SMTP) [1]
reply code, 521, which one may use to indicate that an Internet host
does not accept incoming mail."
That RFC 1846's 521 reply code does not imply that server will
close connection. ( as 421 and 221 implies. )
I says:
---quote--
After issuing the initial 521 reply, the server host MUST do one of
the following two options:
a) Close the SMTP connection.
b) Read commands, issuing 521 replies to all commands except QUIT.
If the SMTP client does not issue the QUIT command after a
reasonable time, the SMTP server MUST time out and close the
connection. A suggested time-out value is 5 minutes.
---end quote--
But that is just side note and not relevant to question.
/ Kari Hurtta
Andrzej Adam Filip
> [...]
> 2) Is there a way to stop sendmail sending bare CR or LF characters ?
> (I don't mind setting up a special mailer for this service).
You may consider using a milter to fix bare LF [MIMEDefang ?]
As I understand sendmail handles bare CR itself (Am I wrong?).
> 3) Any other comments / advice ?
Try milter first otherwise you would be open to mail transfer blocking
by malicious external senders using "random feature" by MS.
In case of problems with milter you may play with queue groups, queue
runners, queue processing order to limit consequences.
[or even use separate queue for old messages, using external script for moves]
--
[pl>en: Andrew] Andrzej Adam Filip : an...@priv.onet.pl : an...@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Confidence is simply that quiet, assured feeling you have before you
fall flat on your face.
-- Dr. L. Binder
----
http://groups.google.com/groups?selm=871w9...@kristel.fsf.hobby-site.com
Bill Cole
Rob McMahon <Rob.M...@warwick.ac.uk> wrote:
> Hi
>
> I've come back after Christmas to find a stuck message on its way to
> Exchange, holding up the queue. The Exchange server had replied
>
> 421 5.5.2 Syntax error (invalid DATA termination)\r\n
>
> and the message was held with
>
> xxx@yyy... Deferred: 421 5.5.2 Syntax error (invalid DATA termination)\n
>
> Effectively blocking all further mail to that server, leaving ~1000
> messages in the queue.
You might want to consider shortening the maximum queue life for
temp-failed messages. More than a day in most cases is
> Now Microsoft say that means
>
> "SMTP filter encountered an invalid DATA terminator
> Some character combinations in DATA may pose a security risk. The
> connection has been terminated.
> SMTP filter event
> Invalid DATA termination"
>
> And it appears the cause was the occurrence of
>
> CR CR . CR CR
>
> in the message. It appears that Exchange is being overly picky (and a
> 421 response seems completely wrong, but I see this has already been
> discussed). On the other hand, RFC8281 says
>
> "2.3.7 Lines
> ...
> In addition, the appearance of "bare" "CR" or "LF" characters in text
> (i.e., either without the other) has a long history of causing
> problems in mail implementations and applications that use the mail
> system as a tool. SMTP client implementations MUST NOT transmit
> these characters except when they are intended as line terminators
> and then MUST, as indicated above, transmit them only as a <CRLF>
> sequence."
>
> So it appears sendmail (8.13.8) isn't conforming to the RFC, either.
What evidence do you have that it is actually sendmail at fault here?
It is far more likely that something created a slightly malformed
message and handed it to sendmail in a manner that prevented sendmail
from doing any fixup on the body, and then Exchange misinterpreted a
<CR><CR>.<CR><CR> in mid-body as a broken message end. `
That's a ridiculous bug for any SMTP implementation to have, but is
about par for the course for the imbeciles coding up Microsoft's
faux-SMTP software...
> So
>
> 1) Does anyone know how to get Exchange to be less picky ?
Dump it?
More seriously, that actually seems like a question you should be
directing at MS. If you paid for their steaming pile of bad code, they
have some responsibility (at least ethically...) to help you form it
into something resembling a working mail server. I'd think that they
would be the experts on that trick as well.
> 2) Is there a way to stop sendmail sending bare CR or LF characters ?
> (I don't mind setting up a special mailer for this service).
Given the near-complete lack of details, it isn't clear why in this case
there was no line-end fixing and dot-stuffing done. The most likely
explanations would be a pathological mailer definition and/or MIME
formatting that makes sendmail view the message body as untouchable.
> 3) Any other comments / advice ?
Look at the origins of that message. Something is probably creating it
incorrectly. Fix that, and your problem disappears.
--
Now where did I hide that website...
Mike Scott
> Hi
>
> I've come back after Christmas to find a stuck message on its way to
> Exchange, holding up the queue. The Exchange server had replied
>
> 421 5.5.2 Syntax error (invalid DATA termination)\r\n
>
> and the message was held with
>
> xxx@yyy... Deferred: 421 5.5.2 Syntax error (invalid DATA termination)\n
>
> Effectively blocking all further mail to that server, leaving ~1000
> messages in the queue.
A silly question, if I may. You say a single message was stuck in this
way, but there was a queued backlog of 1000 or so messages because of
this? That would imply that either (a) the recipient [exchange] server
was refusing to accept /any/ further mail from the [sendmail] source, or
(b) the sendmail server had ceased trying to send other messages in the
queue. Either seems a trifle odd to me. Can you say which is happening?
There seems to me to be something amiss irrespective of discussion about
line terminators - or do I misunderstand something?
--
Mike Scott (unet <at> scottsonline.org.uk)
Harlow Essex England
Rob McMahon
Having got the 421 error back from the Exchange system, sendmail decided
that that system was buggered, and it wasn't worth persuing any
further messages for it. It just skipped the rest of the messages
marking them as "Deferred".
Cheers,
Rob
Rob McMahon
>> "2.3.7 Lines
>> ...
>> In addition, the appearance of "bare" "CR" or "LF" characters in text
>> (i.e., either without the other) has a long history of causing
>> problems in mail implementations and applications that use the mail
>> system as a tool. SMTP client implementations MUST NOT transmit
>> these characters except when they are intended as line terminators
>> and then MUST, as indicated above, transmit them only as a <CRLF>
>> sequence."
>>
>> So it appears sendmail (8.13.8) isn't conforming to the RFC, either.
>
> What evidence do you have that it is actually sendmail at fault here?
In the sense of being liberal in what you accept, conservative in what
you send. Okay, so it's not literally sendmail's fault in the sense of
"shit in, shit out", but it could be more careful in adhering to the
standards.
> It is far more likely that something created a slightly malformed
> message and handed it to sendmail in a manner that prevented sendmail
> from doing any fixup on the body, and then Exchange misinterpreted a
> <CR><CR>.<CR><CR> in mid-body as a broken message end. `
Nah, it could have fixed up the body. It was given CR CR . CR CR (in
two places), and it passed it on. I quarantined the message, hacked it
with an editor to get rid of the initial CR CR, and re-ran it with a
quick -qQ... and it went through okay. sendmail could have done the
same, either deleting the CRs or adding appropriate LFs (and doubling the .)
>
> That's a ridiculous bug for any SMTP implementation to have, but is
> about par for the course for the imbeciles coding up Microsoft's
> faux-SMTP software...
>
>> So
>>
>> 1) Does anyone know how to get Exchange to be less picky ?
>
> Dump it?
If only ... me, I use Cyrus IMAP and thunderbird. Works like a charm.
>
> More seriously, that actually seems like a question you should be
> directing at MS. If you paid for their steaming pile of bad code, they
> have some responsibility (at least ethically...) to help you form it
> into something resembling a working mail server. I'd think that they
> would be the experts on that trick as well.
Yeah, I'm on that case too. I just thought I'd ask here in case anyone
had a quick fix. It does seem like sendmail could do better.
>
>
>> 2) Is there a way to stop sendmail sending bare CR or LF characters ?
>> (I don't mind setting up a special mailer for this service).
>
> Given the near-complete lack of details, it isn't clear why in this case
> there was no line-end fixing and dot-stuffing done. The most likely
> explanations would be a pathological mailer definition and/or MIME
> formatting that makes sendmail view the message body as untouchable.
Sorry, what details would help ? sendmail received the message with the
CR CR . CR CR unencoded, and passed it on. The chunk was marked as
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
I don't like to send the entire message for privacy reasons.
>
>> 3) Any other comments / advice ?
>
> Look at the origins of that message. Something is probably creating it
> incorrectly. Fix that, and your problem disappears.
>
Hmm. Just fix every mailer in the world, and my problem will go away ...
Thanks for your input, anyway. I agree with you about Exchange, but
that's not my call.
Cheers,
Rob
Kari Hurtta
<...>
> Having got the 421 error back from the Exchange system, sendmail
> decided that that system was buggered, and it wasn't worth persuing
> any further messages for it. It just skipped the rest of the messages
> marking them as "Deferred".
>
> Cheers,
>
> Rob
Yes. That makes completely sense. And if persistent host status
is enabled, sendmail probably may skip Exchange system on next queue runs
also for a while.
Real problem is that there no better response code for "need close connection
because of message" (521 does not exists on this meaning as far I know.)
/ Kari Hurtta
421 <domain> Service not available, closing transmission channel
(This may be a reply to any command if the service knows it
must shut down)
Kari Hurtta
> Rob McMahon <Rob.M...@warwick.ac.uk> writes:
> > [...]
> > 2) Is there a way to stop sendmail sending bare CR or LF characters ?
> > (I don't mind setting up a special mailer for this service).
>
> You may consider using a milter to fix bare LF [MIMEDefang ?]
> As I understand sendmail handles bare CR itself (Am I wrong?).
collect.c: ------------------CLIP----------------
switch (istate)
{
case IS_BOL:
if (c == '.')
{
istate = IS_DOT;
continue;
}
break;
case IS_DOT:
if (c == '\n' && !ignrdot &&
!bitset(EF_NL_NOT_EOL, e->e_flags))
goto readerr;
else if (c == '\r' &&
!bitset(EF_CRLF_NOT_EOL, e->e_flags))
{
istate = IS_DOTCR;
continue;
}
else if (ignrdot ||
(c != '.' &&
OpMode != MD_SMTP &&
OpMode != MD_DAEMON &&
OpMode != MD_ARPAFTP))
{
SM_ASSERT(pbp < peekbuf +
sizeof(peekbuf));
*pbp++ = c;
c = '.';
}
break;
case IS_DOTCR:
if (c == '\n' && !ignrdot)
goto readerr;
else
{
/* push back the ".\rx" */
SM_ASSERT(pbp < peekbuf +
sizeof(peekbuf));
*pbp++ = c;
if (OpMode != MD_SMTP &&
OpMode != MD_DAEMON &&
OpMode != MD_ARPAFTP)
{
SM_ASSERT(pbp < peekbuf +
sizeof(peekbuf));
*pbp++ = '\r';
c = '.';
}
else
c = '\r';
}
break;
case IS_CR:
if (c == '\n')
istate = IS_BOL;
else
{
(void) sm_io_ungetc(fp, SM_TIME_DEFAULT,
c);
c = '\r';
istate = IS_NORM;
}
goto bufferchar;
}
if (c == '\r' && !bitset(EF_CRLF_NOT_EOL, e->e_flags))
{
istate = IS_CR;
continue;
}
else if (c == '\n' && !bitset(EF_NL_NOT_EOL,
e->e_flags))
istate = IS_BOL;
else
istate = IS_NORM;
bufferchar:
------------------CLIP END----------------
I read code that way:
bare CR (ie \r) is accepted
bare LF (ie \n) is treated as CR LF
( I do not see that EF_NL_NOT_EOL is set ... )
( And EF_CRLF_NOT_EOL is yet more strange ... )
( And readerr label seems also to be just
'end of message' )
collect.c: ------------------CLIP----------------
readerr:
if ((sm_io_eof(fp) && smtpmode) || sm_io_error(fp))
{
const char *errmsg;
if (sm_io_eof(fp))
errmsg = "unexpected close";
else
errmsg = sm_errstring(errno);
if (tTd(30, 1))
sm_dprintf("collect: premature EOM: %s\n", errmsg);
if (LogLevel > 1)
sm_syslog(LOG_WARNING, e->e_id,
"collect: premature EOM: %s", errmsg);
inputerr = true;
}
if (headeronly)
return;
------------------CLIP END----------------
/ Kari Hurtta
Bill Cole
Rob McMahon <Rob.M...@warwick.ac.uk> wrote:
> Bill Cole wrote:
>
> >> "2.3.7 Lines
> >> ...
> >> In addition, the appearance of "bare" "CR" or "LF" characters in text
> >> (i.e., either without the other) has a long history of causing
> >> problems in mail implementations and applications that use the mail
> >> system as a tool. SMTP client implementations MUST NOT transmit
> >> these characters except when they are intended as line terminators
> >> and then MUST, as indicated above, transmit them only as a <CRLF>
> >> sequence."
> >>
> >> So it appears sendmail (8.13.8) isn't conforming to the RFC, either.
> >
> > What evidence do you have that it is actually sendmail at fault here?
>
> In the sense of being liberal in what you accept, conservative in what
> you send. Okay, so it's not literally sendmail's fault in the sense of
> "shit in, shit out", but it could be more careful in adhering to the
> standards.
Well, this is a very subtle area, and I think there are multiple ways to
read 2.3.7 that are not obvious in how you excerpted it. The missing
part is relevant:
SMTP commands and, unless altered by a service extension, message
data, are transmitted in "lines". Lines consist of zero or more data
characters terminated by the sequence ASCII character "CR" (hex value
0D) followed immediately by ASCII character "LF" (hex value 0A).
This termination sequence is denoted as <CRLF> in this document.
Conforming implementations MUST NOT recognize or generate any other
character or character sequence as a line terminator. Limits MAY be
imposed on line lengths by servers (see section 4.5.3).
MIME is an extension to standard email. In some cases it is very risky
for an MTA to fiddle with the content of MIME-encoded parts, and
sendmail usually avoids unneeded modifications.
I think RFC2821 is intentionally imprecise in this area. I'm not up to a
textual analysis of it and the relevant MIME specs right now to figure
out whether it would be formally right or wrong for an MTA to convert a
MIME text part using bare CR's to CRLF, and I'm not perfectly certain
that it is safe.
> > It is far more likely that something created a slightly malformed
> > message and handed it to sendmail in a manner that prevented sendmail
> > from doing any fixup on the body, and then Exchange misinterpreted a
> > <CR><CR>.<CR><CR> in mid-body as a broken message end. `
>
> Nah, it could have fixed up the body. It was given CR CR . CR CR (in
> two places), and it passed it on. I quarantined the message, hacked it
> with an editor to get rid of the initial CR CR, and re-ran it with a
> quick -qQ... and it went through okay. sendmail could have done the
> same, either deleting the CRs or adding appropriate LFs (and doubling the .)
Deleting any data in the message would be bad.
The only arguably correct approach to fix the message would be to turn
all the CR's to CRLF and do the dot-stuffing. That seems like a
reasonable thing to do for the vast majority of text/plain messages, but
I'm uneasy about the potential for edge cases.
> > That's a ridiculous bug for any SMTP implementation to have, but is
> > about par for the course for the imbeciles coding up Microsoft's
> > faux-SMTP software...
> >
> >> So
> >>
> >> 1) Does anyone know how to get Exchange to be less picky ?
> >
> > Dump it?
>
> If only ... me, I use Cyrus IMAP and thunderbird. Works like a charm.
Understood. I have to deal with Exchange as well, and am glad to have
not encountered this problem myself.
> > More seriously, that actually seems like a question you should be
> > directing at MS. If you paid for their steaming pile of bad code, they
> > have some responsibility (at least ethically...) to help you form it
> > into something resembling a working mail server. I'd think that they
> > would be the experts on that trick as well.
>
> Yeah, I'm on that case too. I just thought I'd ask here in case anyone
> had a quick fix. It does seem like sendmail could do better.
I think you are probably right, and you should definitely make sure you
get this to the attention of the sendmail developers as well. I am
absolutely sure that they have a deeper and more subtle understanding of
the edge cases than I do, and they can actually change the code as
distributed.
> >> 2) Is there a way to stop sendmail sending bare CR or LF characters ?
> >> (I don't mind setting up a special mailer for this service).
> >
> > Given the near-complete lack of details, it isn't clear why in this case
> > there was no line-end fixing and dot-stuffing done. The most likely
> > explanations would be a pathological mailer definition and/or MIME
> > formatting that makes sendmail view the message body as untouchable.
>
> Sorry, what details would help ? sendmail received the message with the
> CR CR . CR CR unencoded, and passed it on. The chunk was marked as
>
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 7bit
>
> I don't like to send the entire message for privacy reasons.
I understand, but that is the interesting part of the message itself: it
should be possible for an MTA to interpret that and do CR->CRLF
translation plus dot-stuffing on such a message, and sendmail should (in
the sense of 'doing the right thing' not of 'how it usually behaves') do
so.
The other interesting details would be which mailer definition sendmail
was using to pass that message and how the message was generated and
accepted by sendmail. I cannot claim to understand all of the possible
cases, but I thought that under some circumstances sendmail will do the
CR->CRLF conversion. The bit of code Kari Hurtta seems to say otherwise,
but I think that's only relevant for incoming mail.
> >> 3) Any other comments / advice ?
> >
> > Look at the origins of that message. Something is probably creating it
> > incorrectly. Fix that, and your problem disappears.
> >
>
> Hmm. Just fix every mailer in the world, and my problem will go away ...
Well, no. Something gave that particular message to sendmail, and if it
was claiming to speak SMTP then that "Something" was itself misbehaving
in the same way you are noting that sendmail is misbehaving. The bare
CR's are not a common enough occurrence for everyone running sendmail to
have also seen this problem, so presumably there is something a bit rare
in the genesis of the message that caused this problem for you. IF that
unusual element is something you control, you can fix it.
Most mailers DO NOT send bare CR's in SMTP. Whatever mailer did so in
this case is broken, and while sendmail arguably should try to repair
the resulting problematic message, the best fix is for that to not be
necessary.
I bring this up in part because I see a lot of really horrendous SMTP
behavior by fairly common SMTP client code, including some versions of
common perl and java libraries intended to make sending mail simple for
coders. If this message was something generated locally with something
of that sort, it might well be fixable.
Rob McMahon
>
>>>> 3) Any other comments / advice ?
>>> Look at the origins of that message. Something is probably creating it
>>> incorrectly. Fix that, and your problem disappears.
>>>
>> Hmm. Just fix every mailer in the world, and my problem will go away ...
>
> Well, no. Something gave that particular message to sendmail, and if it
> was claiming to speak SMTP then that "Something" was itself misbehaving
> in the same way you are noting that sendmail is misbehaving. The bare
> CR's are not a common enough occurrence for everyone running sendmail to
> have also seen this problem, so presumably there is something a bit rare
> in the genesis of the message that caused this problem for you. IF that
> unusual element is something you control, you can fix it.
>
Good call, and an unfair dig from me. I apologize.
This appears to have been created by something called:
H??X-Mailer: Dynamod Mailer
and pumped into sendmail-8.13.6. Not something under my control. (When
you're at a University, remarkably little is :-)
Anyway, the issue seems clear enough to me. Exchange should accept
this, it's not breaking any standards to do so. It's possible that
sendmail should munge it to avoid problems with broken servers, but I
can see the point about leaving the data well alone. This is the first
time this has happened, so it's not like it's an end of the world
problem. A little cron job to spot and quarantine such messages should
be a no-brainer.
Thanks all,
Rob
Peter Peters
So in fact Exchange seems to interpret the CR as a line terminator and
sees the CR CR . CR CR as a DATA terminator. Thinking about the danger
of changing MIME parts one could also argue that Exchange is wrong too.
--
Peter Peters
Bill Cole
Peter Peters <p.g.m....@misc.utwente.nl> wrote:
[...]
> >Well, this is a very subtle area, and I think there are multiple ways to
> >read 2.3.7 that are not obvious in how you excerpted it. The missing
> >part is relevant:
> >
> >
> > SMTP commands and, unless altered by a service extension, message
> > data, are transmitted in "lines". Lines consist of zero or more data
> > characters terminated by the sequence ASCII character "CR" (hex value
> > 0D) followed immediately by ASCII character "LF" (hex value 0A).
> > This termination sequence is denoted as <CRLF> in this document.
> > Conforming implementations MUST NOT recognize or generate any other
> > character or character sequence as a line terminator. Limits MAY be
> > imposed on line lengths by servers (see section 4.5.3).
>
> So in fact Exchange seems to interpret the CR as a line terminator and
> sees the CR CR . CR CR as a DATA terminator. Thinking about the danger
> of changing MIME parts one could also argue that Exchange is wrong too.
I guess you missed what I said earlier in the thread:
: Exchange misinterpreted a
: <CR><CR>.<CR><CR> in mid-body as a broken message end. `
:
: That's a ridiculous bug for any SMTP implementation to have, but is
: about par for the course for the imbeciles coding up Microsoft's
: faux-SMTP software...
It isn't really news that Exchange is garbageware.
Peter Peters
>It isn't really news that Exchange is garbageware.
Don't get me talking. I once threw down a phone when a MS engineer
didn't (want to) understand somebody was using something else between
the Exchange server and Internet.
--
Peter Peters