Jeremy, I closed that bug because the original submitter of the bug refused to provide a test case that demonstrated the bug. So, I had to build my own test case, and my test case worked fine.
I appreciate the work you do on bugs. I would like all bugs in ooRexx to be fixed. I know if you open up a bug, you will have the courtesy to follow up with it when needed. If we need more information, I know you will provide it if we ask. So, please open up a new bug. ;-) I have never, and I have never seen one of the other developers, discourage any one from opening up bugs. Thanks. -- Mark On Sat, Aug 18, 2012 at 2:19 PM, Jeremy Nicoll - ml sourceforge <[email protected]> wrote: > Mark Miesfeld <[email protected]> wrote: > >>On Sat, Aug 11, 2012 at 7:44 AM, Rick McGuire <[email protected]> > wrote: >>> I'm in total agreement with Jerry on this one. This is an area I have a >>> little bit of expertise, having written the Apache javamail > implementation. >> >> Okay, I'll go back and look at that more closely. >> >> My reading of the submitters report was that he had the line immediately >> following the header fields. > > Maybe he did, but more to the point is that if someone uses the smtp class > to send plain text with a colon in it the way he suggested, it does not > work. > > I was a bit disappointed to see that although you did reopen the bug report, > you closed it again almost immediately saying it worked for you. But it > only worked for you, as far as I can see, because you used an example with > the message content wrapped up as a MIME part. > > I've done some experiments and found that plain text content continues to > work if it doesn't contain a colon at the end of the first word, and fails > if it does. I'll attach my test code to this post but I don't know if the > mail-list supports attachments. I don't know if I can attach it to the > now-closed bug report either... > > > I surmised earlier that the commenting out in smtp.cls in the send method of > the line of code that should send the required blank line between headers > and content was why the text-with-a-colon stuff was failing... > > The code in smtp.cls for send in V4.1.1, as distributed, builds various > headers than contains: > > retc = self~strmsock~lineout('Subject:' msg~Subject) > -- retc = self~strmsock~lineout('') > retc = self~strmsock~lineout(msg~content) > retc = self~strmsock~lineout('.') > > On the face of it this would only be expected to work if msg~content started > with a blank line, but it does work if content is eg "This is some text.". I > don't know why that is, unless my mail provider's mail gateway has inserted > the missing blank line when it first sees a line that clearly doesn't > contain a header. It's not impossible that that does happen there, because > I suspect that missing out the blank line is a common fault in code that > tries to send SMTP messages. > > I've also noticed that my mail provider's gateway is also adding a "Date:" > header to my test emails, so for example when I view an arriving test > message it might contain: > > ... > From: [email protected] > To: [email protected] > Subject: testsmtp subj 2 at 18 Aug 2012 22:02:57 - plain text with colon > This: is some ordinary text. > Date: Sat, 18 Aug 2012 22:03:17 +0100 > X-AAISP: Date header line added by h.hopeless.aa.net.uk > ... lots of other X-headers they added > > > If msg~content contains something like "This: is a line" then that line is > treated as a header in the outgoing message because it immediately follows > the generated Subject: line (as shown just above). Such a mail is sent, but > when it is received it has no content. For my tests, when I review the > incoming test messages, the "This: is a line" ends up in the midst of many > headers because others get added to the mail as it travels. > > If msg~content contains a MIME part the mail is sent ok... which surprised > me at first. I wondered why it worked. It turns out that for a MIME part, > content consists of > > some mime-related headers > a blank line > then the boundary-delimited parts > > and this works because the first few headers immediately follow the simple > headers, and the required blank line has been generated in the MIME part. > > > This makes me think that the puzzle (well, I was puzzled) over why the > blank-line-sending code in the send method has been commented out is because > whoever developed the mime aspect of this realised that if the send method's > blank line is produced messages would contain > > all the normal headers, ending in subject: > the blank line from the send method > orphaned headers for the mime stuff > the blank line in the mime stuff > the mime content > > and of course that wouldn't work. (I mean: the mail would be sent but the > recipient's email client would not unpack it properly because the mime > headers telling it how to do that would be in the body text not the main > header block.) > > > It seems to me that the fix for this is quite complicated - beyond me so far > as the oo aspects go. I think what send should be generating is > > all the simple headers > optionally the mime headers if the following content is MIME > the always-required blank line > the content, whether plain text or MIME, dot-stuffed as needed > . > > which would need mime.cls to be able to keep the mime headers and mime > content separate from each other and return them separately to a caller. > That may have ramifications elsewhere; MIME is not used exclusively for > email. I don't know how the ooREXX project normally handles significant > changes in behaviour of previously shipped classes. > > > > I have noticed another error in smtp.cls: > > > ::method Logoff > expose responce strmsock > use strict arg > /* log the user off */ > retc = strmsock~lineout('QUIT') > /* shutdown the socket */ > strmsock~close > /* reset all the defaults */ > self~setdefaults > return 0 > > That expose line is wrong - "responce" should be "response", judging by > other expose statements in the file. But "response" isn't used in that > snippet of code, so maybe it's not required to be exposed at all - unless > the expose has to cascade down to subsidiary methods? > > > > > I did look at the coding of mime.cls and found some issues there too. In > particular there's this: > > > ::method addContent > expose content > use strict arg c > if c == '.' then c = '..' -- we need this for smtp messages > content = content || c || self~crlf > return > > As far as I know, dot-stuffing is (as the comment suggests, and I said in an > earlier post) an SMTP thing, but not a MIME one. There's no way that > dot-stuffing should be being done to lines of data being added to mime > content, especially as someone might use this to build a mime part that's > not going to be transmitted by SMTP. > > Even if it were right to do it here, the code above is not adequate for two > reasons: 1) because it does not consider what happens if someone calls > addcontent with a parameter containing concatenated lines of text, and 2) > because what it should be doing is doubling the leading dot on any line that > starts with a dot (not just altering lines which only contain a dot). > > [In the testsmtp.rex exec that Mark posted in his recent updates to the bug > 2903480 report, he originally had a line of code that called addContent once > with an argument which contained multiple lines of text, so let's not have > anyone suggest no-one would ever do that!] > > The dot-stuffing logic needs to be in the smtp send logic, and must look at > each separate message body line. > > > -- > Jeremy Nicoll - my opinions are my own > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
