Hi Matt, A few notes on your email.
1) Your HELO line is misspelt below to be EHLO. 2) Your code just blindly "dumps" the HELO along with MAIL FROM and RCPT TO and the rest of the message down the line - it does not wait on and check for server responses to these first three. With SMTP, HELO and QUIT could take a little while to occur. On the HELO the SMTP server needs to acquire a lock on the mailbox, on the QUIT it processes any deletions and releases the lock (who knows what else it could be doing). So with multiple clients coming in, you really need to wait to check that you get the lock. 3) Why not use SEND instead of your own code? It will wait on the HELO and check the response. You can add custom headers in using the /HEADER refinement of SEND. 4) Have you checked that the process your server code runs in has the necessary privileges? Perhaps you should add some code to write a log to a text file - to ensure that that it is doing what you hope it is doing. Regards, Brett. ----- Original Message ----- From: "Matt MacDonald" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 04, 2003 2:04 AM Subject: [REBOL] Re: File writing issue > > Sorry for the lack of clarity. Basically, I am implementing a secure > messaging system. This system has 3 components: client software, a > messaging server, and a file server. The messaging server handles most of > the database access of storing and retrieving the messages. The file server > is only for sending and recieving files that users want to send with the > messages. These files are stored on a local drive on the server computer. > This system will be used inside and outside of our company's network. When > used internally, rather than making the users use the client software, I am > sending emails to our exchange server to deliver the messages via Outlook. > So basically what is happening is that once the message is submitted by the > user (external) the message needs to be immediately emailed to the intended > internal user. A temporary solution I'm using is to give internal users > shared access to the servers file store and just insert links to that > location in their emails rather than actually attaching the file. I control > the server, and all machines are windows based machines. > > Here is some code > Client: > insert port encrypt read/binary/direct fpath > insert port "done" > > fpath is the client path to the file on the client computer > > File server: > make-dir to-file dir > file: rejoin [dir fname] > replace/all file " " "_" > write/binary/direct to-file file decrypt read/binary/direct %temp.dat > > where %temp.dat is an encrypted version of the file - the decrypt function > works fine, the file stores fine. dir is the location on the server's drive > to store the file. > > messaging server: > ;compose the MIME formatted message > m: "" > append m "EHLO^/" > append m rejoin ["MAIL FROM:<" return_email ">^/"] > append m rejoin ["RCPT TO:<" user_email ">^/"] > append m "DATA^/" > append m "MIME-Version: 1.0^/" > append m "Content-Type: multipart/mixed; boundary=unique-boundary-1^/" > append m rejoin ["Subject: " subj "^/"] > append m "X-MS-Has-Attach: yes^/" > append m rejoin ["Date: " tstamp "^/"] > append m rejoin ["From: <" return_email "^/"] > append m rejoin ["To: <" user_email ">^/"] > append m build-attach-body message files "--unique-boundary-1" > > smtp: open/lines tcp://10.10.1.8:25 > insert smtp m > insert smtp "." > insert smtp "QUIT" > close smtp > > it is at this point that i normally get the error that the specified file > cannot be opened, but when I go to the location on the drive, it is there > and I can open it manually to verify the contents. If this problem can't be > solved it's not a huge problem because for most purposes, the work-around I > have going now is sufficient. It just seems like this should not happen. > > Thanks to you both, > Matt > ------------------------------------------------------- > Right, you're not being terribly clear > what you are trying to do. Please explain > the system you want to implement. > > What kind of machines are you using and have control over? > > Do you control the server? > > Let's also see the code. > > This sounds like it should be really easy. > > By the way, read and write is used in all the > network protocols, including FTP. > > Anton. > > >Ok, this kindof works, if I put a wait 10 after I write the file to disk, > >but before I email it, the email comes through fine (granted it takes 10 > >seconds longer, but I'm willing to deal with that for now). The problem > >here is that even though everything works ok, I get a network > >timeout error. > > How do I increase the network timeout window? Or is this a really bad > >approach. > >Matt > > > > > > >From: "Matt MacDonald" <[EMAIL PROTECTED]> > > >Reply-To: [EMAIL PROTECTED] > > >To: [EMAIL PROTECTED] > > >Subject: [REBOL] Re: File writing issue > > >Date: Fri, 31 Oct 2003 08:57:43 -0500 > > > > > > > > >That makes sense, but how do I email an attachment that is in memory. > > >Basically this is the scenario: > > >The client software sends a file to the server, this needs to be > >done using > > >read and write commands because FTP is not secure enough. Then once the > > >file gets to the server, the server sends out an email which includes the > > >file. So as far as I can see, the file needs to come from disk and not > > >from > > >memory. I have tried doing a read/binary of the file into a string in > > >memory and manually formatting the message body, but it never > >comes out as > > >the attachment in the email, its just always a text file that has all the > > >binary in it. > > > > > >Matt > > > > > > > > >------------------------------------ > > >I suspect the problem is either in your > > >/direct mode handling, or the build attach > > >code. > > > > > >What happens when you do not use /direct mode? > > > > > >If you write in buffered mode, you have the file > > >contents in memory, so you should be able to > > >write/binary the file, then send straight from memory. > > > > > >Also you can read/binary and compare the contents > > >in memory. > > > > > > contents: read/binary file > > > > > > write/binary file2 contents > > > contents2: read/binary file2 > > > > > > ; compare contents > > > print (checksum contents) = checksum contents2 > > > > > >I know you want to use /direct mode, but until you > > >are bug free... divide and conquer. > > > > > >Anton. > > > > > > >If the file is there allready it emails fine. Its just when I do a > > > >read/binary/direct from one location and a write/binary/direct > > > >from another > > > >location and then immediately try to do anything with it that > >it gives me > > > >issues. > > > > > > > >Matt > > > > > > > >-------------------------------- > > > >Hi Matt. > > > > > > > >If you copy the file manually to the directory, and then attempt to > > > >email it using REBOL, do you get correct results? > > > >If not, how are you determining how many bytes you are sending out? > > > >Does the fiile contain binary data or ascii? > > > >Are you emailing it as an attachment, or as the text body? > > > > > > > >Elan > > > > > > > >Matt MacDonald wrote: > > > > > > > > >Ok here's one more for everyone to ponder. When you write a > > > >file in rebol > > > > >that is somewhat large (around 1 meg or so) and then > >immediately after > > > > >writing it you want to do something with it (email it, etc) I > > > >get an error > > > > >message that the file is not there. On inspection of the > > > >directory where > > > > >it is supposed to be, it is there. So I'm guessing there is a > > > >little delay > > > > >between the time when you write the file (and rebol returns) > > > >until the file > > > > >is really accessable. So I put this line of code in to > >counteract that > > > > > > > > > >while [not exists? file] [] > > > > >to make it wait for the file to be there. > > > > > > > > > >So now I can do things with the file, but not the whole file. > > > >When I email > > > > >it it usually shows up as 64B. So then I entered this line of code > > > > >while [size? file <> fsize] [] ; where fsize is how big the file > > > >should be, > > > > >thinking that the file might get written to the disk in peices > > > >so I want to > > > > >make sure the whole file is there before doing stuff with it. > > > >This didn't > > > > >work either, it did wait, but the file still doesn't come > > > >through complete. > > > > > Any suggestions? > > > > > > > > > >Matt > > _________________________________________________________________ > Enjoy MSN 8 patented spam control and more with MSN 8 Dial-up Internet > Service. Try it FREE for one month! http://join.msn.com/?page=dept/dialup > > -- > To unsubscribe from this list, just send an email to > [EMAIL PROTECTED] with unsubscribe as the subject. > > -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
