The only one of these that I have reservations about is Mail::SendEasy. I'm not real convinced that ripping the guts out of MIME::Lite, Net::SMTP and the rest (metaphorically speaking) and putting them in one place is the wisest idea. For me it violates a bunch of rules. 1)Tools should be simple and single purpose. 2)Tools should be easily usable independently. 3)Code shouldnt be duplicated unnecessarily.

You say that the dependencies are too large for your taste. For me that is a sign of a robust design. Each dependency can be maintained independently by people interested in the relevent field. Net::SMTP handles authentication, MIME::Lite among others handle attachments of a whole range of type correctly and automaticaly. (Meaning it will auto detect the file type and map it the appropriate encoding and MIME type.) M::L can even be used with OpenSSL to create S/MIME mails.

I guess the reason im writing this is that over time my intention with MIME::Lite is to do the exact opposite of what you are doing with SendEasy.pm, that is to move as much of the internals in MIME::Lite that are implemented by stand alone packages into simply using the packages. I say this becuase when I inherited MIME::Lite (which is a very old module) there was all kind of code in there that handled various issues reasonably well but nowhere near as well as the dedicated modules can and do. So for things like email addresses it has code inside it that parses them, but not quite to spec. Wheras it can also call out to Mail::Address and have that parse the address code. Now I dont have to stay on top of the MIME RFC's as well as the SMTP RFC's. And when those RFC's are updated or enhanced, or the author of that module improves his code my module and the all the users of it benefit. Also when you think of testing and exposure using your module represents a severe risk. Your code is new, untested in the wild wheras Net::SMTP and friends have been tested on tens of thousands of machines and work on every platform perl runs on. How many years and bugfixes will go by before we can have the same confidence in your code?

So from my perspective your Mail::SendEasy is probably a maintenance problem waiting to happen. You have to maintain compatibility with something like 6 or maybe 8 different RFC's. Thats a lot of work for a single volunteer author, and I wonder if its really wise to trust production systems to such a tool. I am much more comfortable trusting lib-net which is maintained as part of the core now iirc, Mail::Address for address parsing, MIME::Base64 for base64 encoding (also now part of the core), MIME::Types for mime type detection, etc etc. First off there are less single points of failure (if you get hit by a bus your user base will S.O.L., and given the modules ambitiousness its unlikely to be maintained by someone else), second I believe that by choosing smaller problem spaces to work in the result is more likely to be well maintained.

So, in short I believe that this one module represents what I consider to be the worst reasons to reinvent the wheel.

I will say that i like some of your other work quite a bit though.