Yes, I think these are all good ideas:
1. Add a new email validation method: I was thinking of adding a
boolean isEmail(String email, boolean requireDot) and then making the
current isEmail(String email) just call isEmail(email, false). Would
that work? Or should I just make a new method isEmailWithDot?
2. I think you're right also--we should have the
sendContactListEmail to be a separate service which does not have its
own transaction but uses separate transaction blocks.
3. One issue is how to mark some parties as having been sent an
email, so that if the sendContactListEmail is broken, we can start
from the middle? I was thinking about add an "In use" status code to
"lock" the contact list party while an email is being sent to the
list, but now I'm not sure if it's a good design or not, because you
might want to send several emails at the same time. If not with an
"in use" status code, then what? Does anybody have any ideas?
4. I'm thinking about adding a flag to the contact list to control
whether contact list emails will be logged in each user, to
distinguish between mass-marketing email lists which you probably
don't want to log for fear of choking your database, versus directed
emails such as product recalls, etc.
On Nov 3, 2006, at 9:38 AM, David E Jones wrote:
Maybe the best option would be to have 2 different email validation
methods in UtilValidate (don't want to add an argument, because
some stuff depends on taking a single String argument and returning
a boolean).
Then the ContactList or something could have a indicator on it
specifying whether or not to require a dot after the @.
-David
On Nov 3, 2006, at 4:51 AM, Yoav Shapira wrote:
Hi,
On 11/3/06, David Welton <[EMAIL PROTECTED]> wrote:
> There was some discussion a long long time ago about this and how
> some valid email addresses don't have a dot in them. I don't
know how
> that could be except perhaps on an internal network or something.
[EMAIL PROTECTED]
Yup, that's an example. The general issue is in RFC2821, section
2.3.10. Only the destination host should attempt to parse,
verify, or
manipulate the string after the @. Most of the time this would only
be useful on an internal network where you create aliases and/or run
your own mailing lists inside the network...
Yoav
Best Regards,
Si
[EMAIL PROTECTED]
