On Sat, 30 Jun 2001 13:30:33 +0100 (BST), "J.R.Haynes"
<J.Haynes@???> wrote:
>On Sat, 30 Jun 2001, Marc Haber wrote:
>> Yesterday, I had a broken e-mail on my exim
>> queue that resulted in the following conversation
>
>I have seen exactly the same thing. I also get a huge line in my
>exim_mainlog which says 'malformed SMTP response' and then quotes the
>whole of the notes 500 replies to every line of the message (this makes
>for interest when trying to read the log!)
My exim didn't even log anything besides the timeout.
>> notes: 250
>>
>> Eventually, a time out.
>
>So Exim requeues. However Notes thinks it has sent a 250 so delivers the
>part of the message up to that point. When the next queue run occurs Exim
>redelivers (initially we have short retry times on local mail
>machines) and Notes does the same again so the Notes user gets multiple
>messages.
Exactly.
>> Unfortunately, I don't have the original message any more, but I
>> suspect it contained the hex string "0d 2a" somewhere which notes
>> considered a dot on a single line, believing this to be the message's
>> end while exim was still delivering.
>
>All the ones I have seen look like this. I have successfully edited the
>file to remove the <CR> before the . and it then delivers OK. Usually
>however the departmental Notes support staff tell me just to delete it
>so my tests have not been exhaustive.
As a rule, I do never tamper with a message's contents. So anything
such a message gets is an exim -Mg.
>> Any comments will be appreciated.
>
>I agree with you that it is the fault of Notes. The people who support
>Notes in the relevant department are not quite so convinced.... They say
>that they cannot find anything in the Notes knowledgebase about this. If
>you can find a fix for Notes I would love to hear it.
Unfortunately, I am "only" the firewall admin and only responsible for
the exim installation. The notes machine is (thank god!) the client's
responsibility.
In the mean time, I have studied the relevant RFC2821 (2.3.7) which
says:
"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."
Since notes sees the single CR as a line terminator, this is in
violation of RFC2821, and exim is right in not doubling the period.
The fact that a bare CR is not allowed in an SMTP message (RFC2821
2.3.7) shifts the "real" cause of the problem to the generating client
(which has been - of course again - Outlook Express), but notes is at
fault, too.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
