As a hack to your script, how about adding a simple string test?
cfif not isValid(email, emailVal) or emailVal is not trim(emailVal)
... handle exception ...
/cfif
That would leverage isValid() for the actual string content, but it would
separately catch any address that hadn't been trimmed.
Oh, it's easy enough to work-around. Doing that now.
I'm just saying, it looks like a bug that *shouldn't* need work-arounds.
Jason Fisher wrote:
As a hack to your script, how about adding a simple string test?
cfif not isValid(email, emailVal) or emailVal is not trim(emailVal)
... handle
I'm not entirely sure what you are considering as a bug here. Are you
saying that the isValid is doing a Trim implicitly and you think it
shouldn't? I don't think I'd call that a bug, myself. When I write
validation routines, I tend to trim strings automatically before
running my validation
Basically, yeah. That's a good way to put it - it's doing an implicit trim.
The string going into the IsValid is a legit email, followed by some
other characters - not just spaces.
Those extra charactesrs *should* trip the validation and return false -
but it's not. And even if it were spaces
I would agree that b...@example.comqrst should fail validation.
But what about b...@example.com or b...@example.com some text?
An email to b...@example.com would work just fine. b...@example.com
some text may or may not, I'm not 100% certain how an SMTP server
would deal with that. I'd
I would think the best approach is to regex the email address to remove the
junk, then check to see if it valid using isvalid(). This way your
test...@gmail.comx/,,/xmail.com,/. will parse to test...@gmail.comx and
then return not valid.
6 matches
Mail list logo
