[REBOL] Re: send&email insanity
From: lmecir:mbox:vol:cz at: 7-Mar-2003 9:05
Hi Charles, Scott, myself and all,
> From: "Charles"
> > Okay, I'm officially about to go insane.
I think, that everyone using SEND has (at least once) been "caught" by this bug. I confess,
that I have been too lazy to send my observations to the public and I lazily "circumvented"
the bug.
> Cool, can we watch? :)
> > ...Check this out. (BTW, the only
> > reason I'm altering email addresses is protection against harvesters using
> > escribe):
> > >> outmsg/to: [me--me--net]
> > == [me--me--net]
> > >> outmsg/to
> > == [me--me--net]
> > >> probe outmsg
> >
> > make object! [
> > To: [me--me--net]
> > CC: [[person1--me--net] "," [person2--you--net]]
> ...
> > Content: none
> > ]
> > >> send/header outmsg/to mesg outmsg
> > ;;; mesg is just a string
> > connecting to: mail.me.net
> > >> outmsg/to
> > > ...
> > ?!?!? Where did the To field go?!?
> > Help me before I drop my computer out the window! :P
> Good question. I would be shocked if this one hasn't shown up. I can more
> easily show you wehre the problem is arising, than why. Look at the source
> of the send function. In fact save a copy to a file (it will be helpful in
> a moment).
> echo %/pathtomyfile/send.r
> source send
> echo none
> When you look at the send function, near the bottom, you will see a section
> that looks like:
> ...
> foreach addr address [
> if email? addr [
> do-send smtp-port ["MAIL FROM: <" from ">"]
> do-send smtp-port ["RCPT TO: <" addr ">"]
> if not show [insert clear header-obj/to addr]
>
> that last line is the problem. Before the line is called, the header-obj/to
> and addr both still exist. After that line is called, they both disappear.
> This suggests a context issue. A context-ologist may be able to explain
> "why" (or tell me why it is something else).
>
> It looks like a buglet to me, but I am not certain.
you may safely be certain
> A fix is to change that line to:
> if not show [header-obj/to: copy addr]
> Clean up the top and bottom of this file to only include the function
> definition and then load this replacement for send.
>
> I, too, would like to know from a context-ologist what is happening here,
> and has this been reported, and should it be reported.
>
> Hope this helps a bit.
> --Scott Jones
You correctly found the bug and suggested the fix. I think, that even
if not show [header-obj/to: addr]
fixes the behaviour. Please send your fix to the feedback.
Now to "why"
---------------
As a context-ologist I must state: it isn't a context issue. :-P
Actually, it is an identity issue. :-)
The bug has been "induced" by the desired behaviour. I think, that the desired behaviour
was to change the HEADER object to contain only one address (- the address ADDR of the
present receiver), while the ADDRESS argument of SEND was supposed to contain addresses
of more receivers.
To "achieve" the goal, the buggy code tries to clear the HEADER/TO attribute and append
the current ADDR to it. The bug shows itself, when ADDR and HEADER/TO are identical strings.
Then the CLEAR function clears the HEADER/TO string and therefore it clears the ADDR
string. The fact, that we append the ADDR string to the HEADER/TO string doesn't help.
Hope it explains the issue.
Thanks for the fix and for sending it to the feedback, Scott.
-L
