It would be fine. But relax address control should be only for <FROM>, and <TO>,<CC>,<BCC> and <REPLYTO> should still be validated.
-----Message d'origine----- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Ben Speakmon Envoyé : mardi 4 décembre 2007 21:10 À : Jakarta Commons Users List; [EMAIL PROTECTED] Objet : Re: [email]Email.setfrom differs in 1.1 I would suggest changing the code to allow you to skip the address validation if a system property is set (- Dorg.apache.commons.email.validateAddresses or something). That way you can turn it off now and tighten the screws later on when your conditions allow it. On Dec 4, 2007 8:54 AM, MERLIN Bertrand <[EMAIL PROTECTED]> wrote: > > Absolutely not. > > But i'm in a business context and for the moment, it's work. > > Development is a balance between what developper desire (an address must > be > an address) and a real situation. > > The application is old, there's 50000 users, in an administrative entity, > mail are not yet their each day reality and there are afraid of giving the > way to "be watched". And the management don't want to force the decision. > So > my work must be underground. I try to increase internal quality of > application, to propose new fonctionnalities using valid addresses to make > "new adepts", but for now i must preserve the old functionnalities. That's > life ... > > And javamail has the same constraints and still accept <From> without > valid > adresses. > > And i still need a solution with 1.1 version ... > > Thanks, > > Bertrand. > > > > -----Message d'origine----- > De : Siegfried Goeschl [mailto:[EMAIL PROTECTED] > Envoyé : mardi 4 décembre 2007 17:10 > À : Jakarta Commons Users List > Objet : Re: [email]Email.setfrom differs in 1.1 > > > Hi Betrand, > > are you absolutely sure that no email server and email processing > application will ever drop/reject an email if contains an invalid <From> > address? > > Cheers, > > Siegfried Goeschl > > MERLIN Bertrand wrote: > > hello, > > > > i'm actually using javamail 1.2 + commons email 1.0 in an business > > application > > > > We don't want to enforce users to provide valid from adresses. It's not > a > > serious problem because the mail is still delivered. > > > > We need an evolution and it's the good time to upgrade to javamail 1.4.1+ > > commons email 1.1 ... > > > > But mails are no more delivered because of the : > > > > // run sanity check on new InternetAddress object; if this > fails > > // it will throw AddressException. > > address.validate(); > > > > in Email.createInternetAddress > > > > With javamail 1.4.1 + commons email 1.0, it's still work ... > > > > Is there any way to bypass the control ? > > > > Don't you think that sanity chek is always good for <ReplyTo> but may be > > discussed for <From> ? > > > > thank you for your work and enduring my frenchy way of talking. > > > > > > ------------------------------------------------------------------------ > > > > Post-scriptum La Poste > > > > Ce message est confidentiel. Sous réserve de tout accord conclu par > > écrit entre vous et La Poste, son contenu ne représente en aucun cas un > > engagement de la part de La Poste. Toute publication, utilisation ou > > diffusion, même partielle, doit être autorisée préalablement. Si vous > > n'êtes pas destinataire de ce message, merci d'en avertir immédiatement > > l'expéditeur. > > > > > > > > > > ------------------------------------------------------------------------ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > Post-scriptum La Poste > > Ce message est confidentiel. Sous réserve de tout accord conclu par > écrit entre vous et La Poste, son contenu ne représente en aucun cas un > engagement de la part de La Poste. Toute publication, utilisation ou > diffusion, même partielle, doit être autorisée préalablement. Si vous > n'êtes pas destinataire de ce message, merci d'en avertir immédiatement > l'expéditeur. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Post-scriptum La Poste Ce message est confidentiel. Sous réserve de tout accord conclu par écrit entre vous et La Poste, son contenu ne représente en aucun cas un engagement de la part de La Poste. Toute publication, utilisation ou diffusion, même partielle, doit être autorisée préalablement. Si vous n'êtes pas destinataire de ce message, merci d'en avertir immédiatement l'expéditeur.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
