You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Siegfried Goeschl <si...@it20one.at> on 2007/12/04 17:10:27 UTC
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: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
RE: [email]Email.setfrom differs in 1.1
Posted by MERLIN Bertrand <be...@laposte.fr>.
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 : apacheben@gmail.com [mailto:apacheben@gmail.com]De la part de Ben
Speakmon
Envoy� : mardi 4 d�cembre 2007 21:10
� : Jakarta Commons Users List; bertrand.merlin@laposte.fr
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 <be...@laposte.fr> 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:siegfried.goeschl@it20one.at]
> 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: user-unsubscribe@commons.apache.org
> > For additional commands, e-mail: user-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
> 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: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
Re: [email]Email.setfrom differs in 1.1
Posted by Ben Speakmon <bs...@apache.org>.
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 <be...@laposte.fr> 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:siegfried.goeschl@it20one.at]
> 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: user-unsubscribe@commons.apache.org
> > For additional commands, e-mail: user-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
> 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: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
RE: [email]Email.setfrom differs in 1.1
Posted by MERLIN Bertrand <be...@laposte.fr>.
you're right ! i had just a minor change to do. But i get into the habit of
upgrading components whenever i think about it.
and i was surprised to notice a problem that i could qualify as a regress.
it's quite unusual from Jakarta, so i try to get informations ... and to
give feedback on my use ...
-----Message d'origine-----
De : Torsten Curdt [mailto:tcurdt@apache.org]
Envoye : jeudi 6 decembre 2007 12:04
A : Jakarta Commons Users List
Objet : Re: [email]Email.setfrom differs in 1.1
On 04.12.2007, at 17:54, MERLIN Bertrand 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 ...
Why do you need to upgrade? ...is what I am wondering
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [email]Email.setfrom differs in 1.1
Posted by Torsten Curdt <tc...@apache.org>.
On 04.12.2007, at 17:54, MERLIN Bertrand 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 ...
Why do you need to upgrade? ...is what I am wondering
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
RE: [email]Email.setfrom differs in 1.1
Posted by MERLIN Bertrand <be...@laposte.fr>.
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:siegfried.goeschl@it20one.at]
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: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org