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
20120817-jn-testsmtp.rex
Description: Binary data
------------------------------------------------------------------------------ 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
