I would suggest that the need for directly creating messages be revisited.
It would be much better and scalable approach to directly communicate with
the SMTP server task on port 25 than trying to be inter-twined with the
IMail specifics/internals.
We have used BLAT.EXE (command line utility) and JMail ActiveX (COM Object)
methods to create several specialized utilities to create/send messages
programmatically and have never had any problem with this approach.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of John A. Junod
> Sent: Wednesday, May 26, 1999 6:11 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [IMail Forum] POP3 maildrop questions
>
>
> Could be pretty dangerous, and you will need to use and honor
> our mailbox locking.
>
> MAILBOX LOCKING
>
> The entire package of programs employs a built-in locking
> system to eliminate concurrency problems. Locks are created
> by modifying the first character of a file name and creating
> a special file in the same directory as the locked file. Files
> are only locked while critical reads or writes are being
> performed on the file. Old locks are removed if they are
> more than one hour old. This means a user may be locked out
> of accessing a file or a service for up to one hour as a
> result of a system crash during a critical time period.
> It is possible to manually remove a lock file if you are
> positive that no process is actually accessing that file.
> One reason for the long time period is the amount of time
> required to transmit a 2+ megabyte file across a 2400 baud
> slip connection (who would do that anyway???) with processing
> delays caused by the remote end.
>
> Mailboxes must be locked while accessing them for write
> (or during the verify stage). A file is locked by creating
> a file named by changing the first character of the extension
> to a "~" (or adding ".~lk" to the filename if it doesn't have
> an extension or by adding ".l" to the filename if it has a
> long extension).
>
> A file cannot be opened for write if the SetLocks call fails.
>
> CODE FOR CREATING A LOCK NAME
>
> char szLockName[512];
> PSTR pS;
>
> strcpy(szLockName,szFileName);
> if ((pS = strrchr(szLockName,'.')) != NULL)
> {
> // if there was a period in the path
> if (strlen(pS) > 4)
> strcat(szLockName,".l");
> else
> *(pS+1) = '~';
> } else
> strcat(szLockName,".~lk");
>
> The X-UIDL and STATUS headers are not necessary when adding
> a message to the mailbox. Since you will be forcing the
> system to regenerate the UIDL information since the mailbox
> will have been tampered with. (This causes a delay on
> initial access to the mailbox after you have added a
> message depending on mailbox size.)
>
> Basically, you should never modify or delete a message
> within a mailbox UNLESS you delete the associated UID
> file. Adding a message is ok.
>
> John
>
> In reply to 26 May message from [EMAIL PROTECTED]:
>
> >I'm working on a program that will ultimately be used to add
> >messages directly to a users .mbx file - bypassing the imail SMTP
> >process altogether. ( why? it's a long story... )
>
> >In doing so, as long as all the regular mail headers are there and
> >I set the X-UIDL header to something unique and Status header to
> >'U', should I encounter any problems? I'm pretty sure that these
> >are the only two changes that are made to the message file before
> >it is written to the .mbx file.
>
