What mail module can be used to send email messages with attachments? I would prefer a module included in the perl package by default.
Thanks. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [EMAIL PROTECTED] ----- Original Message ----- From: "Wiggins d'Anconia" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 05, 2003 2:59 AM Subject: Re: Mail::Send question Camilo Gonzalez wrote: > Todd W. wrote: > >> "Camilo Gonzalez" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> >> >>>> Definitely avoid this if possible, there are numerous mail message >>>> modules, one of them is bound to provide what you need. >>>> >>> >>> Why is sendmail held in such low regard by this group? >>> >>> >> >> >> Most on this list will agree sendmail is one of the Internet's first >> "killer >> apps". But because interfacing directly with the sendmail binary can be >> confusing and bug prone there are modules on the CPAN that use >> sendmail as >> the transport mechanism. These modules abstract sendmail's intricacies >> from >> the user, providing a simple API to send mail. Therefore, modules are the >> preferred way to send mail from a perl program. >> >> Todd W. >> >> >> >> >> > I sometimes wonder if all this shielding of intricacies is necessarly a > good thing. Shouldn't I know how to use sendmail? I guess I'm a DIY kind > of guy and I want to know how sendmail works. Fine, if a module makes it > all easier, I'll certainly use it. But I want to know how the > abstraction occurs. What happens if the module I'm using in lieu of > sendmail is buggy and I have no idea why or how to circumvent the > problem? Do I have control issues? > > At the very least these are the right questions to be asking. It really depends on your situation if you are developing an application that is intimately tied to sending email then it is a good thing that you know how to call sendmail, and its intricacies. More important than that is probably how to build an RFC compliant mail message. If this is your situation then maybe a module is not right, however if your situation is doing computationally intensive queries on a bio/genetic database, then who cares how the message goes out that contains the output as long as it gets where it is going, in this case the algorithms for generating the content are far more important and time is better spent on them. That is the other beautiful thing about Perl modules (at least the ones on CPAN) they are open source so you can see how they work if you have the time. When we recently re-architected our app the first step I took was looking into mail sending modules, logging modules, and cryptography modules. I installed all of the variants I could find, became at least proficient with each so that I could accomplish the smallest task that mimiced my end goal and constructed a list of pros and cons for each. In the case of cryptography (gnupg/pgp) the modules that were available ranged from mediocre to very good, but none fit the specific requirements of *my* project, so I built my own, but for mail I found that there were at least two that provided all of the functionality (and much much more) I needed and so I used one of them. In general I have found that there is a middle area where a module is least likely to fulfill my need, and by this I mean in complexity. The more or less complex a task then usually a module can be found that accomplishes the goal, it is the middle ground where a module may not be robust enough to accomplish the task or may have different requirements than mine that usually one can't be found that is just right. For the very complex (like mail) assuming a module exists at all, usually it is better than what I could accomplish in the span of time alotted so I will choose to use it. Most often for simple tasks a module doesn't have to do much and may even be among the standard module base, for instance copying a file across filesystem boundaries. A relatively easy task that could be coded over and over, but with the File::Copy module so accessible why bother.... Just some thoughts... http://danconia.org -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
