in reply to embedding hyperlink using Mail::Sendmail

So what's the problem? Is the URL appearing in the email but not clickable or not appearing in the email? Most modern mail clients will turn a properly formed URL (http://www.foo.bar) into a clickable element.

You may want to check into sending HTML mail (check out the Mail::Sendmail FAQ).

-derby
  • Comment on Re: embedding hyperlink using Mail::Sendmail

Replies are listed 'Best First'.
Re^2: embedding hyperlink using Mail::Sendmail
by jhourcle (Prior) on Aug 26, 2005 at 01:15 UTC

    I'd highly suggest against HTML email -- for it to work consistently for everyone, you'd have to do a MIME alternative, with a plain text component ... so you have to generate two messages, and lots of other overhead.

    Odds are, most people's e-mail browsers are going to look for http urls (and many other of the more common protocols), and handle turning it into a link, if it makes sense for the mail client. If it doesn't, the user is going to be used to dealing with this sort of thing, and can deal with it on their own.

      I too would highly suggest against it but the OP was vague on what he was trying to do.

      Although I recommend against HTML email, I've been getting a *lot* of pressure from clients for HTML email. So I bite the bullet, get them to at least agree to an opt-out to plain text (or preferably an opt-in for html).

      Unfortunately there's not a lot of information about sending HTML email reliably. I would love to see a list of email clients that support/don't support HTML email (or more importantly to what degree they support HTML).

      Right now I use the following guidelines:

      • use MIME::Lite
      • set the Type and Encoding properly
      • use CSS inline (embedded breaks in most web mail clients as does import)
      • always have an opt-out (revert to plain text)

      Right now, some of the market surveys we've done show about a 60/40 love/hate relationship with HTML emails - I think if there was more standarization for email clients (both web and standalone), that number of haters would decrease significantly

      -derby
        Although I recommend against HTML email, I've been getting a *lot* of pressure from clients for HTML email. So I bite the bullet, get them to at least agree to an opt-out to plain text (or preferably an opt-in for html).

        Back when I did consulting (well, I'm technically a consultant now, but it's a long-term relationship, not like the stuff I used to do, which I hated), I found that a lot of times the customer would think they knew what they wanted, but they often didn't have enough information to have made that decision.

        Often, you have to educate them, and help them determine what it is that they really should be asking for, and setting the appropriate expectations for what it is that you're going to be doing for them.

        If someone insists that they really want HTML e-mail, I would try to get them to step back for a second, and determine what it is that they're trying to achieve. Sometimes, what they're trying to do really does require HTML e-mail. Most of the time, however, they can just do it in plain text, and include a URL to 'View the HTML version of this message'.

        Sometimes, you just need to explain the differences in the protocols, the issues with linking in images in HTML e-mail (it's either bulky, or a privacy issue), the general pain in the ass that is HTML, and how getting people desensitized to opening HTML e-mail can result in security issues.