Bonjour,
Je suis en train de faire un projet su Eclipse pour tablette et je voudrais savoir si il y a une fonction en java qui permet de contrôler si l'adresse email saisie est valide .
Merci
Bonjour,
Je suis en train de faire un projet su Eclipse pour tablette et je voudrais savoir si il y a une fonction en java qui permet de contrôler si l'adresse email saisie est valide .
Merci
La notion "d'adresse email valide" n'est pas clairement définie et est surtout une décision à prendre par l'intégrateur. Java ne se substitue pas à cette prise de décision.
Donc non. Mais si tu trouves quelque part une regex qui te convient pour ta validation, tu pourras sûrement t'en servir en Java.
Faux !
Les adresses email sont clairement définies par les RFC (principalement la RFC 822).
Pour autant, la vraie expression régulière n'est pas du tout pratique à utiliser.
Il existe d'autres expressions plus légères : https://www.google.fr/search?q=adresse+email+regex+java
De une je n'appelle pas ça "clairement définie" mais "rigoureusement définie."
De deux cette regex autorise beaucoup de choses archaïques qui sont des erreurs évidentes dans le contexte actuel où on demande une "adresse email" à l'utilisateur.
Je n'ai donc rien dit de faux. La RFC parle d'une notion d'adresse email qui n'est pas la notion actuelle, et ce conflit de notions n'est pas clair. Par ailleurs, les règles qu'elle indique sont rigoureuses, mais pas claires (je suppose que ce serait acceptable de se baser dessus, s'il n'y avait pas le problème du conflit de notions).
Et puis "adresse mail valide" cela dépend fortement du contexte.
"admin@maisonblanche.us" est une adresse mail qui passe la RFC.
De là à dire qu'elle est valide pour un utilisateur.....
Nous on filtre un certain nombre de "keywords" dans le user-name pour "valider" une adresse: admin, robot, www, root, bla, foo, .... plus un certain nombre d'autres filtres dépendant du domaine.
En bref, "Définir la validité d'une adresse" est la première question à se poser.
Vérifier sont bon "format" est une première réponse possible, spécifiée par les RFC, même si je ne pense pas que toto+"me Â"@machine2@machine.com (pourtant bien formée) puisse être correct.
Certes. Les mots sont pas forcément bien choisi.
D'ailleurs, il y a peut être eu une mise à jour de cette RFC ?
C'est une autre approche, mais pour autant, si l'utilisateur ne peut pas se logger alors qu'il possède une adresse du style rootXYZ@azerty.fr, ça peut être gênant non ? Les Keywords sont à ne pas sur-utiliser ?Nous on filtre un certain nombre de "keywords" dans le user-name pour "valider" une adresse: admin, robot, www, root, bla, foo, .... plus un certain nombre d'autres filtres dépendant du domaine.
Non, mais tchize+mailinglist@gmail.com est bien formé, et pourtant, environ 60% des formulaires web me la refusent car "non valide"
machin&partners@machinandco.com est valide, pourtant presque systématiquement refusé
Et dieu seul sait le nombre de vieux formulaires qui trainent sur le web qui vérifient que le TLD est .com, .org, .edu, .mil ou en deux lettres. La cata avec l'ouverture des TLDs. Pareils avec les domaines possédant des accents....
J'ai tendance à dire, si la RFC autorise une email ET votre serveur est capable d'y envoyer un email, alors il n'y a pas de raison de la refuser.
Pourquoi refuser root@mondomainepersoamoi.fr ? Ca n'a pas de sens.
Le truc étant que beaucoup de gens ignorent ce que leur serveur est capable d'envoyer sans essayer d'abord -_-°.
Mais on est d'accord.... le truc c'est que si tu essayes d'envoyer quelques mails à "root@gmail.com" ou "root@xxxxx" (où xxxxxx est un domaine protégé par un spam filter digne de ce nom), il y a 95% de chance pour que ton serveur de mail devienne blacklisté.... et de ce fait soit incapable d'envoyer un mail à qui que ce soit pas la suite.
Pour les TLDs et noms UTF-8 c'est un autre domaine de ... validation du domaine justement. N'importe quelle librairie DNS Client est capable de valider le domaine et de s'assurer que celui-ci a bien les champs MX remplis (condition pour l'envoi de mail). Mais c'est une opération coûteuse en temps, et non réalisable côté client.
Côté client (formulaire): validation javascript de la "forme" de l'email
Envoi du formulaire si tout est bon
Côté serveur: validation du domaine, et des blacklist d'adresses (fournie par la plupart des opérateurs de mail: yahoo, gmail, hotmail, ...). Attention à ce que le serveur colle bien une étiquette "non valide" après refus de l'adresse 1 ou 2 fois, histoire d'éviter de tomber dans une "spam trap".
Pour info, j'ai quelques statistiques:
* sur 100 clicks sur le bouton "send" du formulaire, 70 seulement sont bien formées (pas d'espace, un @, au moins un . après le @...). Donc la validation côté client permet de gagner 30% de "puissance serveur" (c'est exagéré, mais grosso modo).
* sur 100 mails collectés côté serveur (on en collecte environ 1000 par jour), 85 seulement sont des mails corrects et joignables (qui ne renvoient pas d'erreur à l'envoi de mail).
Et bien sur, s'assurer de suivre les procédures DomainKeys (DKIM) et autres amusements du genre
D'ou tu tiens cette idée? Ce n'est pas parce qu'on touche une boite précise qu'on deviens blacklisté. Il faut la toucher suffisament souvent. Et à moins justement de créer un serveur de spam, je ne pense pas que tu va envoyer à tes clients 50 mails par jour. Surtout si le mail d'enregistrement n'est jamais arrivé
Si il suffisait qu'un de tes utilisateurs envoie un email à root@gmail.com pour être blacklisté par SORBS, il y a longtemps que les utilisateurs s'en donneraient à coeur joie On a une boite email au boulot avec 600 users derrière, on a jamais mis en place de politique banissant des destinataires sur cette base et, surprise, on est pas banni ....
Je me suis mal exprimé... Ca c'est la spamtrap... certaines adresses sont des spamtrap.
Chez yahoo par exemple, hitter une spamtrap depuis un serveur mail, grille l'@ ip de ce serveur pendant 12h.... chaud chaud. Plus aucun utilisateur yahoo ne recevra d'email du serveur pendant 12h ! (ou avec 12h de décalage).
Chez google, c'est 2 spamtraps en moins de 48h.
Pour les mails root@ robot@ etc... il en faut généralement plus mais pas forcément beaucoup. Et nombreuses sont les adresses de ce type qui ne correspondent pas véritablement à quelqu'un.
Des agents de certification (comme "returnpath" par exemple) sont particulièrement exigeants quant aux adresses mails utilisées.
Mais bon, tout ceci n'était que pour montrer que chacun a une utilité différente d'une "validation" d'email. Tout dépend de ce qu'on en fait. D'où ma question initiale: "définir validation d'email"
Normalement le spamtrap ne bloque que "le même email" envoyé aux autre boite, cas typique d'un spam envoyé identiquement à plein de monde. Si tu envoie un email personnalisé à la spamtrap, tu ne risque pas de bloquer tes autres emails. Bref, toujours confirmer par un email de opt-in une adresse avant de l'inscrire
sinon, à ce rythme là, j'inscrit la spamtrab de yahoo comme nouvel utilisateur dvp et ça va bien casser les c**** à Anomaly
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager