CVS log for interchange/lib/Vend/Email.pm

Up to [Local Repository] / interchange / lib / Vend

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

fix debug statement

fallback mode implemented for missing MIME::Lite module

specify default character set with MV_EMAIL_CHARSET variables

better solution to implement charset option for [email]

prevent email headers like Attach: HASH(0xc643078)

respect new "charset" parameter for [email], allows sending UTF-8 emails

Copy option hash to avoid messing with caller's data
Unravel code setting reply_to from reply input, primarily
to fix a bug which resulted in "1" as reply-to header

remove obsolete dependencies

* Working Email.pm.
* Compatibility functions for send_mail(), mail() and tag email.
* Should be a drop-in replacement.

There is another part of this commit, that I will add later today or
tomorrow. (Re-directions from traditional send_mail, mail and tag email
to code in this module).

I'd like to give you a chance for peer review or comments before we
actually switch to Email.pm.

Cya folks
-doc

* Updated version of Email.pm

 - Handles headers better (only accepts valid header names)
 - Supports multiple to/cc/bcc/reply-to fields
 - Uses debug/error messages equal/similar to send_mail()
 - Aligned comments the usual way

 Work left to do:
 - Verify header values for malicious input (MIME::Lite already
   takes care about one part of it - it is NOT possible to pass it something
   like  To: user1\nSome-other-header: some-other-value  , because it inserts
   a space after \n so it looks like continuation of previous line. It is
   also not possible to send headers as part of the message, because headers
   and the message itself are passed to MIME::Lite in two separate calls)
 - Wrapper/compatibility functions for existing methods
 - Attachments

 Jon, does the above solve your concerns about header injection? If not,
 do you have a general example of the problem you have in mind?

* Add Email.pm, handling mail functions.

  The module works by help of MIME::Lite and properly handless various
  types of email.

  Shortly, I will add compatibility support so that the existing
  mail functions start calling this module.

  I'll make the "compatibility" functions compatible as possible, but
  given that Email.pm depends on some non-standard Perl modules
  (such as MIME::Lite), are we okay with that, or there should be a
  config option to enable when you want to use Email.pm instead of
  old code?

  Short-term TODO:
  - Support for attachments
  - Write compatibility functions
  - Word-encoding of header fields (did it, but need to troubleshoot)



  If anyone wants to try it, I used the following tag to call it:

UserTag mime_lite_email hasEndTag
UserTag mime_lite_email addAttr
UserTag mime_lite_email PosNumber   0
UserTag mime_lite_email Interpolate
UserTag mime_lite_email Version     $Revision: 1.0 $
UserTag mime_lite_email MapRoutine  Vend::Email::tag_mime_lite_email


  And the usage is [mime_lite_email header(s)=value(s)]...[/mime_lite_email]:

  [mime_lite_email
    to="[value email]"
    subject="Thank you [value fname]"
    from="__COMPANY__ Customer Service"]

    Dear __COMPANY__ customer, ....
    ....

  [/mime_lite_email]