in reply to Re^2: Practical e-mail address validation (Email::Address)
in thread Practical e-mail address validation

The module doesn't appear to provide a way to get the address with quoting and escaping removed so that addresses can be compared.
The following snippet does just that:
use Email::Address; my @addresses = map { Email::Address->parse($_) } <DATA>; print is_equivalent(@addresses) ? '' : 'not ' , "equivalent\n"; sub is_equivalent { my ($a, $b) = @_; return lc $a->address eq lc $b->address; } __DATA__ "John Doe" <jdoe@bla.com> (Johnnie "Two Toes") jDOE@BLA.COM
It also doesn't disallow the very common user mistake of "everybody@gmail" (which can be valid as an e-mail address in some situations but isn't a valid address to give to somebody outside of your organization and so is worthwhile for us to disallow).
That's right. Any validation rules you want to impose beyond what RFC 2822 does is up to you, but Email::Address will tokenise the addresses in order to enable you to. Here's a snippet of how it deals with various address formats:
use Email::Address; my @addresses = map { Email::Address->parse( $_ ) } <DATA>; for my $address (@addresses) { printf("%8s: %s\n", $_, ( $address->$_ or '' ) ) for ( qw( origina +l address user host name phrase comment format ) ); print "-------\n"; } __DATA__ abc@foo.com bla@gmail "Eve Rybody" <everybody@example.com> foo@asdf.com%bar.com "Alan B. Combs" <abc@foo.com> (I can't think of anything complex)
From there you can easily validate $username, $host etc.

Replies are listed 'Best First'.
Re^4: Practical e-mail address validation (Email::Address)
by tye (Sage) on Sep 13, 2008 at 22:11 UTC

    I don't see how your proposed solution does what I requested. It doesn't do any canonicalization of quotes nor escapes. Yes, it eliminates comments. But your test considers jdoe@bla.com to be different from "jdoe"@bla.com, for example. Perhaps there are some other "tokens" I should be asking for instead?

    Yes, I suppose I could go to the trouble of parsing RFC 2822 (except for not allowing abitrary nesting of comments and not allowing CFWS in many places) in order to throw away the parts I don't want and then reparse the other parts to do additional validation and canonicalization. I suspect that will be more code (not counting the code for the module) than the solution I've already written. And it won't allow for simple customization such as allowing /\.@/ as noted elsewhere.

    The module almost does RFC 2822 but doesn't do a good job of practical validation of e-mail addresses typed in by external users. I don't see its contribution to my task being much of a "win".

    - tye