🚀 go-pugleaf

        There seems to be some confusion over which site generates the extra
<CR> in the <CRLF>.<CR><CRLF>. It could possibly be ICE but then if it was
all e-mails would suffer and that doesn't happen.

        Unfortunately there is a cop out the RFC's that you must be:-

        "precise in what you send and vague in what you accept."

        I have yet to find an RFC which tells the whole story. At points
they are imprecise to downright misleading. There is also the problem of
providers who don't work strictly to the RFC's as policy or do not
implement sections that they don't think are necessary. Add to this the
badly set up hardware ( eg Ascend modems ) and you can have endless trouble.

        When I wrote SMTP I worked to the RFC and generated a full
implementation. I then discovered that Demon haven't implemented the TURN in
the half duplex system and had to cover provision for send as a seperate
connection. When Cix came into the picture they sent packets with multiple
commands separated by <CRLF> similar to FTP. It is possible that in the
splitting up of incomming packets to separate the commands from each other
that I could have inserted an extra <CR> but after carrying out test after
test I haven't been able to duplicate the error. 

        However writing Internet access software is unlike any other kind of
programming I have ever done as I don't know the outputs and I have no
control over the inputs. This is why I have separate log/debug files for
each high level routine SMTP, FTP, NNTP etc. Each packet as it is supplied
to these routines is PRINTED to a file generating a blank line between each
packet ( for my own purposes ).

        After checking the packets of mail which comes down I think the
problem of repeating e-mails may stem from the packet being full and the
last <LF> being cut off or ignored by the sender ( The RFC doesn't mention
this ). I have had packet logs in full slip encoding which proves that this
has happened before and may be happening again.

        I could write code which handled every single exception but that is
expensive in memory and costs time in deciding which code to use. Most Atari
users want as much speed as possible and I can't afford the overhead. The
SMTP routine in ICE is non specific and carries out the transfer of mail
perfectly in 'the default RFC circumstances'.

        In the end I have had no choice but to put code into ICE that will
detect that the smtp system has stalled for a 30 second period and it
will then check to see if the last packet received ended with a <CRLF>.<CR>
if so it will then assume the <LF> and advise the server that the email has
been received.
 
        Time will tell if this cures the problem.

        OASIS2/ICE has now been released ( with the SMTP modification ). As
I don't want my software blamed for something which is totally out of my 
control. This would only look bad on me, as practically all providers deny
that any problems exist within their systems or code.

        I hope this ends the problems as far as ICE is concerned.


        PS If you believe that the headers to Daron's news postings are
incorrect to the RFC's can you please state where and what. As far as Phil 
& myself can tell they comply exactly to the specifications. We received a
request from the IAB to make changes in the headers, even though the headers
were an exact copy from NOS, as they have realised that some changes are
necessary to allow for extensions and future modifications. 

        It is not our intention to generate anything less than perfect to
the latest standards. If we have missed something we do not mind anyone
pointing out a mistake as we'll never correct what we think is right.

         Dave.


--

============================================================================
If All The World's Cars
Were Parked End To End: ---~~~>> ///////  ///////  ///////  ///////  //////
                                //       //   //  //       //       //    //
Some Idiot Would Try  ---~~~>> ///////  ///////  ///////  ///////  //     //
To Pass !!!!!                      //  //       //       //       //    //
                    ---~~~>> ///////  //       ///////  ///////  ///////
Dave@levihome.demon.co.uk                         NeST 90:100/114.0@nest.ftn
============================================================================