> I think that the heirloom-mailx version can do all these things since it > supports every mail protocol I can think of.
It's not the protocols, it's the user interface. > we need ... imap (with imaps and starttls support), Handled by curl, to some degree. > pop3 (with ssl and tls support), Already done, mostly by curl. > mbox and maildir support (for local mail), I wouldn't use this; keep mail on the server or put mails on your computer where they really belong. > Correct threading header support (currently it doesn't work correctly, It does, but you have to save email unformatted and browse and re. I need to make this mechanism more convenient from a user perspective, but it is implemented inside. I had to do this a few years ago because people on one of the linux lists yelled at me, each of my emails started a new thread and confused them and I really meant it to be a reply on a current thread so anyways yes I did some of this work. It wasn't hard. I think it's documented somewhere. > Other stuff ... Yes, not sure how vital the other stuff is. > but I wonder if it's time for an edmail program? We can certainly see the advantages of the separate eb js process, now that it's done, and ebmail ebspread etc could make a lot of sense, as long as it's all an integrated system. Bill Gates found this out a long time ago. Some web forms call up email client so you can send email, or even submit form by email, and from within email you can click on a link and go to your browser, and (not speaking of windows but of edbrowse) I can be in the editor and suddenly decide I want to send somebody email and just put subject at the top and type sm and out it flies. I really like that. I really like the integratedness of it all, but that certainly doesn't preclude modularizing the software more than it is today. Karl Dahlke _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
