This is an improvement over last time. That said, I'd change several things.

First, I don't care for the style of parameter passing that operates on elements of @_ directly. I find this much clearer:

sub email
{
    my ($class, $value) = @_;
    return unless $value =~ /^([\w\.\-]{3,})@([\w\.\-]{3,})\.([A-Z]{2,
+3})$/i);

    return "$1\@$2\.$3";
}
[download]

This has the advantage of separating error handling from validation; you get to decide what to do at the caller. That tends to make your designs simpler and more flexible. As I suggested in my previous comments, you can say:

my $email = Validate->email( param( 'email' ) );
push @errors, "Missing or invalid e-mail address '$email'\n" unless $e
+mail;
[download]

If you think of classes and methods as nouns and verbs and put together your programs as if you were describing them in English, you'll find that they can be pretty maintainable.

You really don't need a function to format error messages if you push the responsibility for formatting them back to the caller.

I dislike the use of the ampersand for function calls as there's no reason to use it. (You're not invoking a sub reference nor do you need to bypass prototypes. Save yourself a sigil and skip it.)

I don't see any reason to use require instead of use for Validate. It's shorter. Also, you can use the nicely descriptive class method syntax if you use a package statement within the Validate package.