1. User requests page
2. Server generates page
3. Server sends page to user
4. Browser renders page

At this stage (although I'm simplifying a little), the page exists only in the browser's cache - and there is no way for you to retrieve that from the user's browser (short of playing around with JavaScript to post the entire page back to the server - but that would be even sillier then generating the data again (not to mention unreliable).

You might want to consider doing with the vast majority of websites do and allow the user to just copy and past the URL from their address bar into their email client. Saying "Please trust us with your friend's email address" can leard to concerns that you are harvesting addresses to spam.

You might want to consider doing with the vast majority of websites do and allow the user to just copy and past the URL from their address bar into their email client

Not feasible. The HTML in question is in an intranet, not the open net. I need to email the page the user sees.

# Create a user agent object
  use LWP::UserAgent;
  $ua = LWP::UserAgent->new;
  $ua->agent("MyApp/0.1 ");

  # Create a request
  my $req = HTTP::Request->new(POST => 'http://search.cpan.org/search'
+);
  $req->content_type('application/x-www-form-urlencoded');
  $req->content('query=libwww-perl&mode=dist');

  # Pass request to the user agent and get a response back
  my $res = $ua->request($req);

  # Check the outcome of the response
  if ($res->is_success) {
      print $res->content;
  }
  else {
      print $res->status_line, "\n";
  }
[download]

• grabbing html source (normal)
• XML
• print

Using a templating system e.g. Template Toolkit (see also merlyn's articles on Template Toolkit) can make it easy to create browser and email views of your content based on reusable components.

Like Dorward's solution, this is a win-win situation, because you also get the 'visit' to your page which helps with stats,

I'd go for this solution also because of the following reasons:

1. No need to download page from your own server
2. Way more friendly for the recipient:
   1. Smaller email
   2. User might not have a client that can handle HTML

And if the URLs are terribly long, you might even throw it through one of the WWW::Shorten modules.

--
b10m

All code is usually tested, but rarely trusted.

Some other issues to think about are how big the pages might be. Sending really large emails from your web server might end up creating more challenges than re-requesting a page.

Also, if the recipients may not have access to the intranet content, you'll have to work around the fact that images and other included content won't be seen. Maybe you only need the text of the page, so it won't matter. But if things like images are important to the look of the page, you'll need to send the page and the images. That could make for a fairly large email.