Estaba configurando la validación de un formulario en el que decidí intentar usar la función filter_var para verificar la validez de mi dirección de correo electrónico. No puedo averiguar qué filtro_var realmente permite en cualquier lugar (ya que la documentación es muy simple), y descubrí que está permitiendo una dirección de correo electrónico como test @ test. ¿No tiene que haber un .com, .net, etc. en el dominio?
El comportamiento ha cambiado alrededor de abril. Ver bug #49576 y revision 297350.
Ese correo electrónico es realmente inválido, o al menos eso es lo que entendieron los desarrolladores de PHP. La fuente lleva presente anuncio:
/*
* The regex below is based on a regex by Michael Rushton.
* However, it is not identical. I changed it to only consider routeable
* addresses as valid. Michael's regex considers [email protected] a valid address
* which conflicts with section 2.3.5 of RFC 5321 which states that:
*
* Only resolvable, fully-qualified domain names (FQDNs) are permitted
* when domain names are used in SMTP. In other words, names that can
* be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
* in Section 5) are permitted, as are CNAME RRs whose targets can be
* resolved, in turn, to MX or address RRs. Local nicknames or
* unqualified names MUST NOT be used.
la changelog menciones esta corrección de errores para PHP 5.3.3 y PHP 5.2.14.
El ticket para este error está marcado como fijo desde PHP5.3.3 y PHP5.2.14 – Gordon
Excelente captura Artefacto. Entonces, ¿supongo que las reglas han cambiado? ¿Por qué ha cambiado esto? Me gustaría que explicaran lo que están verificando en la documentación de filter_var. Entonces, ¿esto volverá verdadero antes de 5.3.3 y falso después de 5.3.3? El sistema en el que estoy usando esto es 5.2.12 – Metropolis
@Metro Comprueba si el correo electrónico cumple con los estándares de Internet. El hecho de que 'test @ test' se permitió antes era un error. – Artefacto
Es una dirección de correo electrónico válida. No va a funcionar en Internet (al menos, no hoy), pero está bien para una dirección local.
Supongo que los desarrolladores están tomando el enfoque sensato para verificar las direcciones de correo electrónico y no construir un sistema que está garantizado que se desactualizará tan pronto como se introduzca un nuevo TLD. Tenemos suficientes inspectores de sintaxis de direcciones de correo electrónico que rechazan [email protected] tal como están.
¿Cree que la sección 2.3.5 de RFC 5321 no se aplica? – Artefacto
No, test puede ser un dominio de red local/interna, por lo que funcionaría. Me gusta que valide correctamente [email protected] al desarrollar, por ejemplo.
Un normal nonexistentdomain.foo tendría el mismo problema. Si desea probar si algo se puede entregar a un host, use getmxrr (y el que falla vuelve a gethostbyname()).
Entonces, ¿es mejor permitir direcciones locales? ¿O debería usar getmxrr junto con él si no quiero permitir algo como test @ test? – Metropolis
¿No sería mejor verificar usando checkdnsrr? Porque si su servidor está inactivo, o algo más, entonces getmxrr devolverá falso. ¿Derecha? – Metropolis
Permitiría direcciones locales (principalmente en intervalos de IP conocidos) si desea/espera manejarlas. Podrías usar checkdnsrr ('nombre de host', 'ANY'), no se me ocurrió (aunque revisar el registro MX o A (que debería ser la alternativa si no se definiera MX) sería más confiable: un dominio registrado puede no tener registros A & MX, lo que los hace inentregables). checkdnsrr/gethostbyname/getmxrr todos utilizan el mismo mecanismo afaik, por lo que si un servidor DNS está inactivo o lento, fallará/será lento para todas las opciones. – Wrikken
test @ test es sintácticamente válido.
de RFC 5321:
En el caso de un dominio de nivel superior utilizado por sí mismo en una dirección de correo electrónico, una sola cadena se utiliza sin ningún tipo de puntos.
Sólo después de esto qué dice:
, nombres de dominio totalmente calificados Sólo resolubles (FQDN) se permiten cuando los nombres de dominio se utilizan en SMTP. En otras palabras, los nombres que pueden se resuelven en RRs MX o direcciones (es decir, A o AAAA) RR (como se discute en la Sección 5), como son CNAME RR cuyos objetivos pueden ser resueltos, a su vez, en MX o dirección RRs. Los apodos locales o los nombres no calificados NO DEBEN ser utilizados.
Esto no excluye necesariamente los nombres de dominio TLD. De hecho, ejecute el código siguiente:
checkdnsrr('ua', 'MX') // Returns true
getmxrr('ua', $array) // Returns true
nombres de dominio TLD de sólo (CAN) tienen registros MX y son en uso: http://www.to/ es un ejemplo.Y aquí es algunas direcciones de correo electrónico de nombres de dominio TLD sólo válidas:
Vince @ ai
paul @ IO
root @ kilómetros
Joost @ tk
admin @ tt
hostmaster @ ua
Fuente de correo electrónico de ejemplo addre sses: Tony Finch – TLDs with MXs
Técnicamente, 'test' podría ser un nombre de host válido en una red local, así que supongo que es correcto. –
¿Puedes publicar tu código? var_dump (filter_var ('test @ test.', FILTER_VALIDATE_EMAIL)); devuelve falso para mí! – Youssef
prueba @ prueba sin el punto devuelve falso también – Youssef