CategoriasHonesting

Actualizamos el diseño de la web

Estamos llevando a cabo una puesta a punto del diseño de la web, así como de toda la estructura de guías, información de servicios, etc.

La zona de usuarios ha sido movida a panel.honesting.es para un acceso más directo y cómodo.

Esperamos que te guste la nueva web y en cualquier caso, nos gustaría saber tu opinión.

CategoriasHosting

Restaurar tu cuenta tras pérdida de datos

El panel de control de tu plan de hosting, te permite realizar copias de seguridad siempre que quieras, completas, sólo de la base de datos, los filtros del email, etc.

Si has perdido algún dato de tu cuenta por error, o te han hackeado la cuenta, puedes restaurar siempre que tengas una copia previa.

  1. Entra en tu cPanel,
  2. Luego en la sección Respaldo
  3. Restaurar un Respaldo del Directorio Home
  4. Haz click en el botón Seleccionar archivo y busca la copia de seguridad que tengas en tu equipo local.
  5. Click en de Cargar
  6. La restauración tardará dependiendo del tamaño de los ficheros.

 

Semanalmente, realizamos copias de todas las cuentas, por lo que aunque no hayas hecho copia previa tendrás a tu disposición de forma gratuita una copia con todo el contenido. Puedes descargarla haciendo:

  1. Entra en tu cPanel
  2. Luego en la sección Respaldo
  3. Click en el botón weekly

 

Luego puedes restaurar utilizando esa copia. Si lo prefieres también puedes contratar soporte adicional para que restauremos.

 

Para cualquier otra aclaración ¡contactanos!

CategoriasHosting

Políticas de seguridad en la empresa

La crisis nos está dejando muchas lecciones que aprender. Algunas nuevas, y otras viejas historias olvidadas en la gestión empresarial, por ejemplo el ya clásico de hacer copias de seguridad que todos sabemos y pocos hacen. Tareas repetitivas que se puede automatizar, pero que en mayor o menor grado siempre requieren de supervisión y atención humana.

No son divertidas, ni sexys ni cools, y por eso nadie se acuerda del paragüas hasta que truena. Sirva este post de advertencia para perezosos.

  • Ejemplo, la trabajadora en baja por depresión: hace unas semanas, nos pasó un caso donde la persona encargada de la gestión del dominio y el hosting, estaba tratando de negar el acceso a la empresa en cuestión. Cambiaba contraseñas casi a diario, y en general molestaba enviando emails amenazantes sobre los derechos que pensaba había adquirido por registrar el dominio a nombre de la empresa donde estaba trabajando. Si la persona que gestiona las contrataciones se toma una baja o despido ¡cambia todas las contraseñas antes! Crea también un documento donde definas qué personas tienen acceso a determinados datos, con varios niveles de responsabilidad. En el futuro te evitará muchos problemas, y si eres una sociedad SL, SLU o SA ¡no es opcional! es obligatorio para el cumplimiento de la ley de protección de datos.
  • Ejemplo, el informático desaparecido: la crisis aprieta en todos los sectores, entiendo que haya empresas que busquen la mejor opción en el mercado. Pero contratar al amigo de tu vecino que hace webs no tendría que ser una opción en el entorno empresarial. Nada evita que de un día a otro el informático desaparezca de la faz de la tierra, se evaporice, y te encuentres con que no tienes acceso a tu propio correo. Hay miles de empresas serias y profesionales que te pueden hacer una web efectiva, sí, te saldrá más caro porque ellos tienen menos margen, ¡tienen que pagar impuestos por todo! tu a cambio obtendrás una garantía de servicio, y en caso de problemas tendrás una factura que podrá demostrar que tu dominio es realmente tuyo.
  • Ejemplo, el informático maltratado: la informática en general está poco valorada en España, cualquiera puede dar golpes en el teclado y llamarse a sí mismo informático. Hay mucha competencia desleal, y eso hace que el que realmente dedica su vida profesional a la informática acabe quemado de oir frases como la de más arriba del amigo del vecino. Si tienes la suerte de contar en tu empresa con un buen informático, aquel que te soluciona los problemas sea a la hora que sea, y que se ha implicado durante años en tu empresa, trátalo bien si tienes que prescindir de él. Es de buena educación, y además ¡tiene acceso a todos tus datos! Aprende a hacer copias de seguridad antes de despedirlo, reúne todos los accesos que vayas a necesitar. Y si no queda otro remedio para reducir plantilla, explícale bien la situación y sobretodo pagale lo que le debas.
  • Ejemplo, el cliente maltratado: tendría que ser parte de la política de seguridad de tu empresa, el garantizar el buen trato con los clientes. En el mercado altamente competitivo en el que nos movemos, cobrar 10 veces más por el mismo producto o servicio deja de ser una máximización de los recursos y pasa a ser tener la cara muy dura. No trates a tu cliente como si fuera tonto, tiene las herramientas necesarias para buscar otra alternativa. Y además ahora tiene el tiempo necesario puesto que el ritmo de trabajo será menor. Lo tiene ahí, a un sólo click. Ofrécele un servicio profesional con un precio ajustado al segmento en el que te quieras posicionar. No compitas en precio con cualquier nueva empresa que surja, no caigas en lo fácil. ¿Cómo vas a explicarle esa factura de 300€ por registrar un dominio?

En general, todas las medidas explicadas se resumen en tratar a la gente como personas, haremos un mundo mejor si prestamos atención a los pequeños detalles.

CategoriasDesarrollo web

¿Cómo modificar los valores PHP por defecto?

Al crear tu página web, es posible que necesites modificar los valores que utilizamos para todas las páginas web y cambiar algunos límites de PHP.

Gracias a la configuración de los servidores, puedes hacerlo fácilemente siguiendo estas instrucciones:

  1. Crea un fichero de texto vacío llamado .user.ini y súbelo a la carpeta /public_html de tu dominio.
  2. Añade los valores que quieras modificar.

Ejemplo de un fichero .user.ini que modifica los valores PHP por defecto:

post_max_size = 256 M
upload_max_filesize = 128 M
set_time_limit = 3000
max_input_vars = 5000

Para saber qué valores puedes editar con el fichero .user.ini puedes consultar la lista de directivas de php. Los que aparecen en la columna de Changeable como PHP_INI_PERDIR y PHP_INI_USER se pueden modificar.

Recomendaciones

Aumenta el valor sólo hasta lo que necesites, poner números muy altos puede interferir negativamente con el correcto funcionamiento de tu web: haciendo que cargue más lenta, genere errores, etc.

Borra el fichero .user.ini una vez hayas terminado de realizar el trabajo.

.user.ini reemplaza el uso de los antiguos ficheros .php.ini, si encuentras algún fichero .php.ini viejo en tu espacio, puedes borrarlo ya que no se tiene en cuenta.

Asegúrate de que el fichero .user.ini no tiene ninguna extensión tipo .txt o .doc.

En caso de dudas, consulta con tu programador web o contrata uno de los bonos de horas para que hagamos el cambio en tu cuenta.

CategoriasHosting

La contraseña perfecta

¿Quién no se ha preguntado alguna vez si su contraseña no es segura?, esta es una pregunta tan típica cómo obligada teniendo en cuenta que es a menudo la única puerta que separa a la gente de nuestra información más confidencial y es que cómo bien dice la wikipedia una contraseña es una forma de autenticación que utiliza información secreta para controlar el acceso hacia algún recurso.

Pero, ¿Que debemos entender por contraseñas seguras?
A mi modo de entender podemos asegurar que una contraseña es fuerte cuando contiene letras mayúsculas y minúsculas y un mínimo de 8 carácteres, sin embargo para Microsoft una contraseña segura debe tener como mínimo:

  • 1 minúscula (a)
  • 1 mayúscula (A)
  • 1 número (0)
  • 1 símbolo (@)

Y una longitud MÍNIMA de 8 carácteres
Siendo así ‘P@ssw0rd’ el ejemplo ideal.

  • Lamentablemente en muchos de los sistemas que utilizan una contraseña no se admiten símbolos, o sólo se pueden introducir un número limitado de caracteres, como 6 ú 8, e incluso los hay de sólo 4.

Un usuario nos explicó su truco para sacar contraseñas largas y luego poder acordarte de ellas… el truco no utiliza símbolos y la longitud de las contraseñas puede ser variable por lo que reune dos de las características que necesitamos.

El truco es hacerlo a partir de nombres de pelis, canciones, libros, versículos de la biblia, frases hechas…

Por ejemplo, se puede sacar la segunda y penúltima letra de:

«Más vale pájaro en mano que 100 volando»

ááalarneanuuod

  • Con una pequeña transformación nos queda (Alternar mayúsculas y minúsculas):
    • ÁáAlSrNeAnUuOd
  • Y añadiendo el número
    • ÁáAlSrNeAnUu10Od
  • Claro, siempre se puede aplicar la misma regla al número:
    • ÁáAlSrNeAnUu0Od
  • Y por dar un último quiebro cambiamos un cero por una C:
    • ÁáAlSrNeAnUuCOd
  • Aunque bueno, bién pensado, se puede añadir al principio un «más vale» de forma simbólica:
    • +>ÁáAlSrNeAnUuCOd

Como todo, esto es una forma, pueden hacerse miles de formas, usando diferentes trucos y tranformaciones, también, se pueden dar más pasos o menos, en función del gusto, y como en Bricomanía, aquí el toque personal cuenta mucho.

Bueno, de nada sirve todo esto, si apuntamos la contraseña en un papel, y nos olvidamos el papel en el peor lugar que se nos pueda olvidar.

A primera vista el método puede parecer un tanto enrevesado e incluso absurdo pero es muy seguro ya que nos evitará sufrir alguno de estos típicos ataques:

  • Fuerza Bruta: Es la razón más común por la cual los administradores obligan a colocar largas contraseñas con números, se trata de recuperar una clave probando todas las combinaciones posibles de caracteres hasta encontrar aquella que permite el acceso.
  • Ataque diccionario: Un ataque del diccionario consiste en el intentar de “cada palabra en el diccionario” como contraseña.
  • Keyloggers: El keylogger es un diagnóstico utilizado en el desarrollo de software que se encarga de registrar las pulsaciones que se realizan sobre el teclado, para memorizarlas en un fichero o enviarlas a través de internet.
  • Mirada ajena: Cuando cualquier persona conocida o no trata de ver que has tecleado y de este modo averiguar tu contraseña.Conclusión

Cómo se puede ver el truco propuesto evita cada uno de estos ataques, el primero de ellos el de fuerza bruta dependerá de la longitud de la semilla tomada… el ataque diccionario será inútil debido a que nuestra contraseña final no se parecerá en nada a cualquiera de la de los diccionarios, los keylogger no seran un problema porque al teclear nuestra contraseña seguramente lo hagamos siguiendo los paso de la creación y algún momento utilizaremos el ratón para cambiar la posición del ratón (Los keylogger no registran las acciones del raton) y por último si alguien intenta averiguar mirando que es lo que tecleas es muy díficil que pueda recordar lo que has introducido debido a su complejidad.

CategoriasDesarrollo web

Evitar spam en formularios PHP

Los formularios de los sitios web que se procesan y se envian a una dirección de correo electrónico pueden ser aprovechados por los «spammers» para hacer envios masivos de «spam» utilizando los servidores de correo y la IP de la maquina en la que se aloja el dominio. En este manual vamos a ver como podemos hacer que nuestros formularios sean un poco más seguros, evitando los ataques del tipo «email injection» a los que muchos formularios son sensibles.

1. En que consiste el «email injection»

Un ataque a un formulario del tipo «email injection» consiste en que el «spammer» aprovecha un formulario de un sitio web para «inyectar» cabeceras de email con direcciones y contenidos diferentes a los establecida en el formulario. Un «spammer» puede, a través de la inyección de cabeceras cambiar tanto el mensaje enviado, como los destinatarios, utilizando nuestro servidor de correo y nuestra maquina y nuestro dominio como emisor del mensaje, con lo que seremos nosotros los que estaremos haciendo «SPAM», y el rastro hasta el «spammer» se pierde.

Aquí tenemos un correo de ejemplo:

To:direccion@destinataria.com
Subject:Motivo del mensaje
From:direccion@emisora.com
Este seria el cuerpo del mensaje.

Dicho esto, la técnica utilizada por el spammer es incluir y/o alterar las cabeceras del mensaje por las suyas propias, antes de que se produzcan 2 saltos de línea, y por tanto, comienze el cuerpo del mensaje. Si el spammer consigue alterar o introducir sus cabeceras, los destinatarios y el cuerpo del mensaje se pueden alterar. Asi por ejemplo, si tenemos el siguiente correo:

To:direccion@destinataria.com
Subject:Motivo del mensaje
From:direccion@emisora.com
To:nuevadireccion@destinataria.com
Cc:otradireccion@spameada.com
Subject:Nuevo subject del mensaje spameado
Texto introducido por el spammer.

Este seria el cuerpo del mensaje.

Observamos que después del «From:» original, el «spammer» ha añadido un nuevo «To:» y otras direcciones de correo con la etiqueta «Cc:». También ha introducido un nuevo texto en el cuerpo del mensaje. El hecho de que haya 2 cabeceras «To:», o 2 «Subject:», no supone ningún problema. En la mayoría de los casos, si una cabecera se define 2 veces, la última es la que se tiene en cuenta.

Un correo básico se compone normalmente de 2 partes: las cabeceras, y un cuerpo del mensaje. Sin embargo, utilizando cabeceras especificas a tal fin, un correo pude tener varios «bodys» o cuerpos de mensaje alternativos. Por simplificar analizamos aquí la estructura de un correo básico.

2. Como puede el spammer inyectar cabeceras en la función mail() de PHP

La función que habitualmente se utiliza en PHP para enviar a una dirección de correo electrónico los datos de un formulario será mail(). La sintáxis de esta función es la siguiente:

  • mail (To, Subject, Mensaje, Headers, Parametros_Adicionales);

El siguiente es un script de ejemplo básico de un formulario que se enviará a una dirección de correo:

  • $to=»webmaster@website.com»;//direccion destinataria «hardcoded»
    if (!isset($_POST[«send»])){
    // si no vienen datos-> mostrar el form
    ?>To: webmaster@website.com
    From:
    Subject :
    Message :

    }else{
    // si vienen datos POST.. procesamos y enviamos los datos del form
    $from=$_POST[’sender’];
    // send mail :
    if (mail($to,$_POST[’subject’],$_POST[’message’],»From: $from\n»)){
    // si se ha enviado correctamente mostramos un mensaje de OK
    echo «Su mensaje se ha enviado correctamente a $to.»;
    }else{
    // Se ha producido un error
    echo «Su mensaje no se ha podido enviar»;
    }
    }
    ?>

En el ejemplo anterior, mostramos un formulario de contacto donde el usuario puede incluir el From, el Subject del Mensaje y el Mensaje. El destinatario «To:» esta «hardcoded» y en principio un usuario no tiene la opción de alterarlo. Sin embargo, esto no nos garantiza nada tal y como hemos visto anteriormente. Un usuario spammer, aprovecharía el campo «From:» para introducir sus propias cabeceras. Solo tiene que añadir un salto de línea al campo del formulario e insertar otras cabeceras. El caracter hexadecimal «%0A» es el equivalente a un salto de línea. Por tanto, si el spammer introduce en el campo «From:» el siguiente contenido:

  • direccionFrom@ficticia.com%0ATo:nuevadireccion@destinataria.com%0ACc:otradireccion@spameada.com%0ASubject:Nuevo subject del mensaje spameado%0A%0ATexto introducido por el spammer en el cuerpo de texto.

Cuando se procese el formulario, las “headers” maliciosas llegarán a la función mail() y gracias a los saltos de línea introducidos en el campo From. Los últimos 2 saltos de línea marcan el comienzo del “body” y a partir de ahí, todo lo demas formará parte del cuerpo del mensaje. En nuestro ejemplo, el spammer no necesita hacer esto último, ya que tiene un campo en el que puede introducir su propio mensaje, pero esta técnica muestra como se puede alterar hasta el cuerpo del mensaje una vez que podemos inyectar nuestras propias cabeceras. El mensaje de correo que devolverá la función mail() será el siguiente:

To:direccion@destinataria.com
Subject:Motivo del mensaje
From:direccion@emisora.com
To:nuevadireccion@destinataria.com
Cc:otradireccion@spameada.com
Subject:Nuevo subject del mensaje spameado
Texto introducido por el spammer en el cuerpo de texto.
Este seria el cuerpo del mensaje.

Que como vimos anteriormente, produce un envio a direcciones diferentes de las previstas, y con otro Subject y Body. Logicamente, el spammer puede introducir tantas direcciones separadas por comas como quiera, con lo que en un simple envio pueden salir cientos de correos SPAM desde nuestro formulario.

En formularios más restrictivos, en los que el cuerpo del mensaje esta «hardcoded» y no se coge desde un campo del formulario, el spammer puede añadir una cabecera del tipo: «Content-Type: multipart/mixed; boundary=»SeparadorDePartes», que permitiría crear un mensaje multi-partes. En un mensaje del tipo «multi-partes», se establece una cadena como «separador» que marcará donde comienza y termina cada parte. Asi, «–SeparadorDePartes», marca el comienzo de una nueva parte del mensaje, que terminará cuando se encuentre nuevamente otro «–SeparadorDePartes» que indique el comienzo de otra parte. Finalmente, «–SeparadorDePartes–» con dos guiones al final, marcaría el final del cuerpo del mensaje.

Utilizando esta cabecera y otras similares, un spammer puede ocultar el cuerpo del mensaje originalmente establecido, dejandolo fuera del separador que marca el fin del body. También podría utilizar esta técnica para añadir ficheros adjuntos, ya que cada una de las partes puede tener su propio «Content-Type», y por tanto podemos hacer que una de las partes sea una imagen o un fichero binario, como se puede ver en esta ejemplo de «email injection» avanzado.
Soluciones

Después de habernos extendido en la explicación del problema, con el fin de que quede claro como se produce, podemos sentir un poco de pánico, aunque en realidad la solución o soluciones (hay varias) son bien sencillas.
Detectar los saltos de línea con expresiones regulares

La más abordable inicialmente es proteger nuestro script para que no le lleguen cabeceras indeseadas. Hemos de tener especial cuidado en todos aquellos campos de un formulario cuyo destino sea el parametro «headers» de la función mail(). En nuestro ejemplo básico el «From:». En lugar de pasarlo directamente, tendremos que hacer una comprobación sobre estos campos y asegurarnos que no vienen saltos de línea, en cuyo caso podemos estar sufriendo una «email injection» y podemos detener el script:

$from = $_POST[«sender»];
$from = urldecode($from);
if (eregi(«\r»,$from) || eregi(«\n»,$from)){
die(«Posible email injection»);
}
?>

También es recomendable utilizar librerias como la Zend_Mail para enviar correos. Esta libreria realiza varias comprobaciones de seguridad antes de enviar el correo, de forma que el usuario no tiene que preocuparse por estos aspectos. Existen otras librerias para el envio de correos que también toman este tipo de precauciones. En cualquier caso, no es menos cierto que existen muchos más scripts hechos personalmente con usuarios poco o nada experimentados y que son el objetivo de los spammers. Para ellos va este Post, a ver si entre todos les ponemos las cosas un poco más dificiles a los spammers. Cuidado con los formularios del tipo «Send to a friend»

Es algo obvio pero como observo que todavía es una practica extendida veo aconsejable recordar lo siguiente. Las medidas de seguridad mencionadas en este manual le protegen o tratan de hacerlo del uso pernicioso que algunos spammers pueden hacer de un formulario previsto con otra funcionalidad.

Sin embargo, poco o nada se puede hacer con algunos formularios del tipo «send to a friend» o «enviar a un amigo» que no han observado la más mínima medida de seguridad. Me refiero a esos formularios que permiten a un usuario anónimo rellenar un formulario en el que todo se puede establecer: El «To:», el «From:», el «Subject:» y el «Body:». Estos formularios pueden ser utilizados como proxies de correo por cualquiera, «spammer» o no. Cualquiera puede enviar un correo a la dirección que quiera, con el subject que quiera, el cuerpo del mensaje que quiera, y simular la dirección desde que lo enviará que quiera, y sin necesidad de utilizar ninguna técnica ni hack para inyectar cabeceras.

En fin, se que es una obviedad, pero había que comentarlo porque hay muchos formularios así. No utilize NUNCA este tipo de formularios sin tomar precauciones obvias de seguridad. Aseguese al menos de que el «From:» no puede ser establecido por el usuario, enviando los correos desde una dirección «fija». Limite las posibilidades de introducir un «Subject:» o un «Body:» personalizado y siga las reglas de filtrado explicadas en este post para evitar ataques «email injection».

Para seguir leyendo :

* https://www.securephpwiki.com/index.php
* https://blogs.pathf.com/highperf/2006/05/php_spam_inject.html

CategoriasDesarrollo web

Como Trabajar Correctamente con PHP

Trabajar con PHP implica tener ciertos conocimientos avanzados en cuanto a configuración y puesta en marcha de los scripts.
Existen Scripts los cuales precisan la activación de ciertos parámetros del lado del servidor los cuales no estan activos por defecto ya que hoy en dia no son usados, demandan demasiados recursos, o bien son inseguros; sin embargo los podras activar e implementar bajo tu plena responsabilidad. Uno de los parámetros no activos por ya no ser muy usados es register_globals, sin embargo algunos scripts antiguos que pululan por la red requieren su activación.

PASO 1
En la carpeta public_html existe un archivo especial llamado .htaccess en el cual insertaremos las instrucciones necesarias especificas para este tipo de archivo, como ejemplo activaremos el register_globals: php_flag register_globals on luego guardamos y ahora si ya estará activo el párametro, de la misma manera si necesitamos activar mas parámetros lo haremos desde ahí.

¿Que pasa al instalar PHPSuexec?
La mayoría de los usuarios no notarán el cambio en el funcionamiento de su página Web, ya que seguirá funcionando todo tal y como les funcionaba antes del cambio, los únicos que tendrán problemas serán los alojamientos que utilicen el .htaccess para unas determinadas cosas, que explicamos posteriormente, y los que tengan permisos en alguna carpeta o en algún fichero 777.

Problemas con .htaccess
Los alojamientos que utilicen .htaccess para activar las register globals, con PHP_FLAG, aparecerá un error 500 al abrir la página, para solucionar esto, es decir, para activar las register globals con SUEXEC, lo tendrán que hacer a nivel de directorio, es decir, las register globals se tienen que activar para cada directorio del alojamiento, hay que crear un archivo llamado php.ini que contenga la siguiente línea:

register_globals = On;

Los .htaccess que contengan valores para PHP_VALUE también darán error 500 en la página, debido a que con SUEXEC no es posible usar ese tipo de directivas.

También generaran error los .htaccess que contengan la directiva ForceType, la cual hay que sustituir por SetHandler, por poner un ejemplo:

Antes de PHPSuexec:
ForceType application/x-httpsd-php

Con PHPSuexec debería cambiar por:
SetHandler application/x-httpsd-php

Problemas más comunes que pueden aparecer con php SUEXEC
Si con la implantación de php SUEXEC usted detecta fallos tipo 500 internal server error, lo primero que tiene que hacer es lo siguiente:

1.- Comprueba los permisos de los archivos y carpetas de tu alojamiento, no pueden superar ninguno los permisos 755, por defecto, todos los archivos subidos mediante ftp tienen los permisos 644, con los cuales funcionan la mayoría de los scripts, pero si algún script requiere de permisos más estrictos, con 755 deberían funcionar sin ningún problema.

2.- Asegúrate que tu .htaccess no contiene directivas tipo PHP FLAG/VALUE o ForceType, ya que estas directivas necesitan hacerse de otra forma tal y como se ha explicado en este manual.

PASO 1
En la carpeta public_html crear un archivo llamado php.ini en el cual insertaremos las instrucciones necesarias especificas para este tipo de archivo, como ejemplo activaremos el register_globals: register_globals = On; luego guardamos y ahora si ya estará activo el párametro, de la misma manera si necesitamos activar mas parámetros lo haremos desde aqui.

De esta manera se logra trabajar correctamente con los diferentes parámetros que requiere PHP.

 

CategoriasHosting

Sender Policy Framework

SPF (del inglés Sender Policy Framework) es una protección contra la falsificación de direcciones en el envío de correo electrónico. Identifica, a través de los registros de nombres de dominio (DNS), a los servidores de correo SMTP autorizados para el transporte de los mensajes. Este convenio puede significar el fin de abusos como el spam y otros males del correo electrónico.

El envío SMTP entre servidores

Cuando se envía un correo desde un programa cliente de correo electrónico, éste conecta con un servidor SMTP (a través del puerto TCP25) al que le deja el mensaje para su envío a una o varias cuentas de correo destinatarias. Este servidor (servidor del remitente) es el encargado de conectar con el servidor donde está alojada la cuenta de correo del destinatario (servidor del destinatario) y de transmitir el mensaje para su almacenamiento y posterior descarga por el destinatario.

En el protocolo SMTP, obviamente, es imposible tener autenticación acordada entre todos los servidores de correo. Este inconveniente permite que cualquier servidor remitente pueda identificarse como el transportista en origen de un nombre de dominio. Esto lo aprovechan los suplantadores de identidad de direcciones de correo electrónico para llevar a cabo su fin.

En el envío de correos no solicitados (spam) y otras malas artes como el phishing o envío de virus por correo, en casi la totalidad de los casos, interesa ocultar el remitente real o utilizar una dirección que al cliente le podría resultar familiar o confiable.

Un primer intento de controlar esta laguna técnica es el seguimiento de la ruta de direcciones IP por las que se envía el correo, de tal manera, que se mantiene unas listas de IP’s de servidores que envían correos falseados (listas negras). Esto, aparte de requerir un proceso manual por parte del destinatario, tiene efectos no deseados sobre otros usuarios del servidor que envían correos «reales».

La solución SPF para evitar falsas identidades

SPF extiende el protocolo SMTP para permitir comprobar las máquinas autorizadas a enviar correo para un dominio determinado. La idea es identificar las máquinas autorizadas por su dirección IP, y que esta identificación la haga el responsable del dominio que recibirá el correo.

Una aproximación a la solución podría suponer que el remitente del correo, hace los envíos desde la misma máquina que los recibe. Como se puede resolver la dirección IP a donde se enviarían correos al remitente a través del registro MX del servicio DNS (RMX, del inglés Reverse MX), si esta dirección coincide con la que genera el envío, se puede entender que es el remitente real. Pero esta suposición no siempre es cierta, especialmente en grandes proveedores de soluciones de correo como Yahoo!, Hotmail, o GMail.

Otra propuesta, la DMP (Protocolo de Servidores de Correo Identificados, del inglés Designated Mailer Protocol), consiste en que los proveedores de servicios de internet identifiquen las máquinas responsables del envío del correo. Esta solución es válida, pero para que sea efectiva requiere que todos los proveedores la adopten e implementen.

Como mezcla de estas dos propuestas, surge la idea de usar registros DNS para identificar las máquinas autorizadas para envío de correo (sean del proveedor de servicios de internet que sean). Esto es lo que se propone en la solución SPF.

SPF en honesting.es

Para activar SPF de forma gratuita en tu cuenta alojada en honesting.es entra en tu cPanel en la sección Autenticación de e-mail.

cPanel_X_-_(Autenticación_de_e-mail)_-_2014-05-28_09.55.52

SPF no garantiza que tu dirección de email o IP no sea añadida en una lista negra, o sea identificado como spam si se realiza abuso o envios no solicitados, haz un buen uso de la tecnología para mantener Internet limpia 😉

Otras opciones

También puedes activar DomainKeys Identified Mail (DKIM), un mecanismo de autenticación de correo electrónico que permite la validación por el destinatario

CategoriasHosting

Formas de enviar un email y limitaciones

Con el fin de garantizar un buen servicio de email, los planes de hosting cuentan con límites en el número de emails que puedes enviar en 1h:

  • Plan Base: 100 emails/hora
  • Plan PRO: 250 emails/hora
  • Plan Pyme: 300 emails/hora
  • Plan Empresa: 500 emails/hora

¿Por qué se aplican límites?

Principalmente, como medida para luchar contra el envío de spam y para evitar que las direcciones IPs de los servidores se detecten como emisoras de correo basura.

Incluso si tienes una lista de destinatarios recopilada por medios propios, puedes correr el riesgo de que tus emails se detecten como spam si haces un envío masivo o en bloque a un único proveedor.

Por ejemplo, envías el boletín de noticias a 600 suscriptores y 120 de ellos utilizan una dirección de un proveedor gratuito tipo @gmail.com o, aunque usen otros dominios, alojan en servidores de @gmail.com de forma indirecta.

Los 120 emails llegan en cuestión de segundos, de golpe, con lo que aumentan las posibilidades de que vayan directamente a la bandeja de spam y no sean leídos por sus destinatarios.

¿Cómo fraccionar el envío por lotes?

La mayoría de aplicaciones especializadas en el envío de boletines, incluyen una opción para hacer el envío fraccionado. No hay un número concreto que pueda garantizarte que el envío llegue a la bandeja de entrada, pero mientras menos envíes en 1h, más posibilidades tienes.

Si te sirve a modo de orientación, el boletín de Honesting se fracciona en grupos de 30 emails máximos por hora. Cuando no hay prisa en que se envíen los emails, un fraccionamiento en lotes pequeños mejora la recepción de los mismos.

En el caso de que tus envíos tengan cierta urgencia (ofertas limitadas en el tiempo, promociones que caducan en unas horas, etc.) siempre puedes ampliar a un plan superior con un límite de envíos mayor.