World: r3wp

Is this a one fire mechanism?  When I do this, and get an error, 
and print it .. or whatever, and if I generate the same error again, 
it then drops to the standard error handler ignoring my error handler.

Do, I need to reset the trap somehow?

Also it is good to add some protection against infinite error cycling.(for 
example if an error occurs in some loop/timer/port etc. executed 
code).

and .. wrong channel ...

I have a question for you guys.

go!

I want to improve the esmtp:// protocol to fix a few bugs reported 
to RAMBO... and make it more conformant to the RFC

so... it needs to send out EHLO instead of HELO

should it fall back to HELO if EHLO fails, or should we tell users 
to use the old smtp:// protocol if they are dealing with an old server?

what is the drawback of fallback?  security risk?

no, it's just not esmtp anymore :)

i mean, if noone in the world will ever need the fallback, there's 
no point in adding it. in weird cases when you have to work with 
some 15 years old server, you may just use the old smtp:// protocol.

as long as you make the error obvious, I guess its better to be strict 
about it.

fall back.

if you write a simple smtp server in rebol you might just want to 
support helo only

graham - did you stumble on any servers not liking EHLO? if you did, 
then I guess we need to fallback

no, actually, you can support EHLO and have no extensions.

not supporting ehlo in a server makes your server not rfc compliant

let me check if my own smtp server supports ehlo :)

http://www.compkarori.com/vanilla/display/Smtpd.r

suports EHLO .. so I guess you're okay!

i think you're the person that better knows how smtp servers behave 
out there. :)

there are some pretty ancient smtp servers out there ...

if an ordinary user would stumble into the problem, then it's probably 
better to fallback.

that way we only need one protocol ..

Gabriele, why don't we run without the fallback for a while to see 
if it will affect anyone. I don't see the reason to add code "just 
in case" when there might in fact be no case like that.

You could keep the fallback code in there ready to be uncommented 
when someone complains.

anton, it might only be a couple of lines to fall back.

and I would think most email clients would fall back ...

it's not a big deal indeed, it just means disabling the rest of the 
code - that's why it seems quite weird to me :)

It's not worth the hassle of not putting it in.

How about net-logging a prominent message when falling back ? That 
way, it should eventually turn up in someone's log, and we'll see 
it that way.

good idea... that way any techie does not miss it, if its at all 
important.  and any average user, gets improved mileage without the 
hassle.

Anton, it will be in the build ... do you really want to update all 
builds once someone reports a problem

ok, i guess i will add the fall back.

I'm just always trying to find "the correct thing to do".

I am accepting #4143. note, that although i think it is unlikely, 
this change could break old code that made assumptions about switch. 
so please do test this one when released (i assume 2.7.2), and if 
it breaks code, we can revert to the old switch, and maybe add a 
refinement or something like that.

anyone has the original contents of #3056?

can anyone check if #3666 still applies?

gabriele, is 3056 not listed in http://www.rebol.net/cgi-bin/projects/share.r?id=35&
?

http://www.rebol.net/cgi-bin/projects/share.r<--- interesting, I 
don't remember this page?

the urls for various code submissions contain spaces, so that breaks 
all the links

ah, that script is still working? :)

#3666 "CALL interferes with UDP ports"  - doesn't seem to apply on 
Windows Rebol/View, I've tested about 30 versions so far.

Just to be sure... when running the second server, I should expect 
a print out of "false-awake-event" to indicate the bug, shouldn't 
I ?

I didn't see this printout on any Rebol/View 1.2.1.3.1 -> 2.7.0.3.1

#3666 applies to Linux: 1.3.2.4.2 and OpenBSD

re #4143: as I mentioned elsewhere, I would prefer FIND/LITERAL or 
changed FIND/ONLY to get more expected result for datatypes

(and I guess, that #3666 may apply to OSX too)

(Ladislav, well, I'm sure of that now !  I should have paid attention 
to the version numbers.)