Scary.

• You don't need to call srand. It even can make things worse.
• Repeated calls to rand won't improve the quality of the random number, because rand is implemented as a pseudo-random number generator. Implicit rounding due to int makes the result even less random.
• You don't test that the folder $foldername exists. This is a good thing, because you would otherwise create a race condition. But you also don't test if mkdir failed because the folder already exists (EEXIST). So you may end writing several different mails into the same folder.

The whole idea of bypassing conventional e-mail handling looks just wrong.

• No one can access his/her e-mails except by your still-to-be-written web mailer. No IMAP, no POP3. (I prefer having my e-mails in my mail client, because every single web mailer I've ever seen just sucks in one way or the other.)
• You will have to spend a considerable amount of time in the webmail code to reconstruct what MIME::Parser did. Probably you will have to call MIME::Parser again. Double work, nothing won.
• Are you sure that you get the file permissions right? How do you prevent malicious users from reading other users' e-mails?
• Premature optimization, probably because you wrongly assume that you will need to parse each and every mail in your webserver. Often, you only need to parse the mail headers, because the user will never read the e-mail or its attachments, e.g. for spam or stalking mails.
• You need to have your SMTP server and your webmailer on the same machine, or at least both have to use a shared storage (NFS). At that point, things become really complicated, and you will end doing something that maildir (see below) already does. Probably, you will do it wrong (because it is hard to do it right), and lose some e-mails.
• You will have a hard time switching to a different mail server because you have to re-integrate your hack into the new mail server.

I think you should have a look at IMAP::Client. Did you know that you can very efficently fetch just the headers of an e-mail via IMAP? This is optimal for a webmailer when you want to show the contents of a mailbox. Simply because you do less work for the same result. So, you should really use IMAP to access the e-mails.

Access via IMAP also allows you to cleanly separate mail server and webmail. It allows you to switch mail servers without having to touch a single bit of your webmailer code. You can even use your webmailer to access several different IMAP servers in parallel.

I think that you should run MIME::Parser only on demand, i.e. when displaying a mail in your webmailer. You could add a caching layer (i.e. inherit from MIME::Parser and add caching logic) that avoids calling MIME::Parser more than once for any given e-mail, storing not only the attachments, but the entire state of MIME::Parser into a (set of) files in a directory accessible only to the owner of the mail. Find out if Storable, Data::Dumper, or some other class can help you serialising and unserialising MIME::Parser objects. Benchmark that! The native e-mail format serialises the same data, and perhaps it is faster to have MIME::Parser parse that format again than to reconstruct a MIME::Parser object from Storable or Data::Dumper.

Sure, running MIME::Parser inside the webmailer slows down the webmailer. Benchmark how much it will slow down. With typical small mails (less than 1 MByte), I would bet that MIME::Parser is so fast that you won't notice any delay at all. For larger mails, do what others to when the user has to wait for a long-running action: Show an animation. In a web mailer, you would typically use an animated GIF, using a little bit of JS and CSS to show it overlaying the current page immediately before the mail view page is loaded. It doesn't speed up things, but makes your users more patient.

If you really, really want to avoid IMAP at all costs, have a look at maildir, maildir++, and IMAPdir. They give you an instant "one e-mail == one file" solution, with no need for locking, and with unique file names. You can use the file name, minus the info (flags) part, as a key for caching already-processed e-mails.

Alexander