World: r3wp

No rush ...

I need it to be fully operationnal for tomorrow, we're starting UAT 
for a customer app relying on it. ;-)

Correcting myself about my claim regarding CRLF not sent by REBOL 
built-in protocols : REBOL does send CRLF even if 'newline if used 
as line terminator. A conversion is applied and it becomes CRLF once 
inserted in the port. This automatic conversion (LF=>CRLF) is OS 
independent and is triggered by /lines refinement used on OPEN native 
in root-protocol/open-proto. AFAICT, this behaviour is not documented 
explicitely anywhere. I can just find a few mentions about such conversion 
here : http://www.rebol.com/docs/core23/rebolcore-12.html, but it 
looks like it's related to FTP scheme only (while in fact being the 
default for all schemes relying on OPEN-PROTO).

yess.  I've had to battle this in the past when its not desired.

I wonder if the /lines is a recent refinement or if I just never 
noticed it.

IIRC, it's here, at least, since v2.0.

here=>there

darn, a single little thing goes unnoticed and this ends up causing 
so much grief!!  :-)

bad side of working with black boxes...

<sigh!>  I wish I'd known about /lines hehe... I had to go through 
countless hours trying to fix the headers and when doing multipart... 
god... it was horrible to fix.  ;-)

I ended working in binary mode exclusive, this way I could at least 
get precise lenghts... which didn't change halfway through the process 
 ;-)

exclusively.

most rfcs of that time user crlf

Well, as soon as it is updated ... I'll be ready to test the MTA.

SVN r21 :


FEAT: log verbosity handling refactored, now more consistent across 
modules

FIX: email.r lib doesn't interfere anymore with other Rebol built-in 
schemes
FIX: bug in multipart/form-data decoding in RSP.r
FIX: email.rsp demo script now handles attached file correctly

wow that was quick!

and the windows 7 issue?

Couldn't access my Win7 box, so could test it. I'll be able to do 
that only tomorrow.

If you're still having issues with the MTA, please active maximum 
log level : -vvvvv and send me the output on private channel or by 
email.

so could (not) test it...

Did encapping solved your DNS lock up issue on Win7?

Yes... but now the new encapped version won't run.

Hmm... will do another svn up

try source version...

Testing from fresh checkout : error popping up at start

Fixed in SVN r22, please update.

win-get-dns: does [ return 208.67.222.222 ]

So, you have to hardcod the DNS server IP address?

to run as source ...

ending progress: [error [compkarori-:-gmail-:-com] {421 4.4.5 Server busy, 
try again later. 8si31346080pzk.8^M }]

sending ..

let me try my own dns

nope... not working.  just says pending.

oh ... ok.  got something back!  :(

someone doesn't like me ... ...sending progress: [error [compkarori-:-gmail-:-com] 
{421-4.7.0 [203.97.98.9] Our system has detected an unusual amount 
of unsolicited^M }]

421 code might be used for greylisting...

Ok, sent to myself .. and worked.

After reading http://en.wikipedia.org/wiki/Greylisting, I'm think 
that I really need to support that feature.

ie. my own domain .. so it looks like gmail now has greylisting

BTW, in Chrome the attachfield does not show up.

Doesn't like me using 209.85.222.8 ( read dns://gmail-smtp-in.l.google.com 
)

just get pending ...

I see the name of attached file once pick up using Chrome 3.0/Vista.

oh .. so you need to select a file first to see the field?

Interesting .. didn't know Chrome was that smart.

I'm in transition from IE8 to Chrome...still lacking some features 
of the google bar (which doesn't yet exists for Chrome!).

can we log the entire smtp transaction so that we can see what the 
issues are?

I've only managed to send 1/10 emails so far.

it would need some additional log/info lines in MTA.r to follow the 
whole exchange. If you have wireshark installed, it will be quicker.

ok.  I'll fire up wireshark.  But my users won't be able to do that.