Procesando el correo

Características

Ahora moodle hace mejor uso del protocolo SMTP y correo en general. La mayoría de las mejoras provienen de utilizar una técnica conocida como Variable Envelope Return Path (Variable envolvente de la ruta de retorno) (VERP).

Funciona en los más modernos MTAs (al menos en los sistemas Unix).
Se aseguran todos los procesos de rebotes y réplicas utilizando HMAC-MD5-8.
Los rebotes (bounces) se manejan correctamente e incrementa el almacenamiento de "correo erróneo" ("bad email") para el usuario.
La dirección noreply@host está ahora en el campo Reply-to (Responder), evitando la contaminación accidental de los libros de direcciones( agendas) de los usuarios.
noreply@host tiene un autorresponder
Facilita a los módulos el envío de correo con la opción VERP reply-to (responder) marcada.
Maneja la recepción de respuestas VERP: Valida la firma de HMAC-MD5-8 y envía los datos requeridos codificados al módulo indicado.

Configuración Moodle

Edite config.php para habilitar manejo de rebotes (bounce), y configure las especificaciones de Moodle para que coincidan con su configuración MTA. Aquí está cómo: Quite los comentarios a estas líneas en el archivo config.php (si no puede encontrarlas, cópielas del archivo config-dist.php):

 // once handlebounces is true, we will be using VERP for the return address of every sent
 email (con handlebounces en verdadero. utilizaremos VERP para coger la dirección origen de
 cada email enviado)
 $CFG->handlebounces = true;
 // minimum bounces allowed per user(rebotes mínimos por usuario)
 $CFG->minbounces = 10;
 // ratio of bad emails to sent emails(estadística de correo erróneo en correo enviado)
 // if we get more than 20% bounces ( si es mayor del 20% los rebotes) 
 // for a given user, his/her email is marked bad(de un usuario concreto, su email se marca
 como erróneo)
 $CFG->bounceratio = .20;

Edite la línea $CFG->maildomain y una de las líneas $CFG->mailprefix (la que coincida con su MTA).

Asegúrese de que su servidor tenga un intérprete de línea de comando PHP, y que sea posible conectar con mysql (o postgres). Si es capaz de ejecutar cron.php desde la línea de comandos o desde crontab, significa que PHP funciona.

Edite el script process_email.php para que contenga la localización de su binario PHP. Será de la forma /usr/bin/php.

Asegúrese que process_email.php sea ejecutable utilizando la instrucción "chmod ugo+rx process_email.php".

Configuración bajo Postfix

Añada una línea a su archivo aliases. La línea contendrá un prefijo de 3 letras, un signo "+" y la ruta al script. Por ejemplo, si el prefijo es mdl y moodle instalado bajo /var/www/moodle tendríamos en el alias:

   mdl:     |/var/www/moodle/admin/process_email.php
   noreply: |/var/www/moodle/admin/process_email.php

Si está utilizando dominios virtuales, consulte al administrador de su sistema para la configuración correcta. Probablemente incluirá editar transportes y mapear su dirección a una "pila("pipe")de transporte.

Configuración bajo Qmail

Dependiendo de su configuración, su alias se controlará por una o más de

/etc/aliases
/var/qmail/alias/.qmail-PREFIX

Si edita /etc/aliases añadiendo una línea como (para un prefijo 'mdl'):

   mdl:     |/var/www/moodle/admin/process_email.php
   noreply: |/var/www/moodle/admin/process_email.php

Si crea /var/qmail/alias/.qmail-PREFIX, simplemente realice

 echo "|/var/www/moodle/admin/process_email.php" > /var/qmail/alias/.qmail-mdl
 echo "|/var/www/moodle/admin/process_email.php" > /var/qmail/alias/.qmail-noreply

A este prefijo de tres letras, añadiremos un signo '-' cuando enviemos y recibamos mensajes. Para más información, compruebe el manejo de dot-qmail.

Configuración bajo Exim

Abra /etc/exim/exim.conf y añada a usuarios de confianza(trusted_users) el usuario Apache y cron.php se ejecutará así (generalmente "www-data" o "nobody").

Añada una línea a su archivo alias. La línea contendrá un prefijo de 3 letras, más un signo "+", y la ruta del script. Por ejemplo, para un prefijo de mdl tendremos en el alias:

   mdl:     |/var/www/moodle/admin/process_email.php
   noreply: |/var/www/moodle/admin/process_email.php

Si está utilizando dominios virtuales, consulte al administrador de su sistema para la configuración correcta. Probablemente incluirá editar transportes y mapear su dirección a una "pila("pipe")de transporte.

Puede encontrar aquí mas documentación sobre Exim. Puede que tenga que indicar a Exim que no ponga en minúsculas la parte local(local-part).

Información para el Desarrollador

Funciones cambiadas:

email_to_user() pondrá la dirección del remitente en un rebote(bounce)especial de procesamiento de direcciones (basado en las especificaciones de $CFG)
email_to_user() aceptará (y pondrá) una cabecera de respuesta(reply-to), que se generará en el módulo que llame a la función.
cambios/adiciones en cadenas asociadas

Nuevas funciones:

generate_email_processing_address() - utilice SIEMPRE ésta para generar la cabecera de respuesta. La cabecera tendrá este aspecto: (LIMITE: 64 caracteres) prefijo - EXACTAMENTE cuatro caracteres codificados , enpaquetados, id de módulo (0 for core)(2 chars) hasta 42 caracteres para los módulos que los rellenarán con lo que corresponda( puede contener id de usuario( o, p.ej. para el foro, id de remitentes(postids) para responderles)),42 caracteres es el LIMITE ABSOLUTO) 16 caracteres hash (half an md5) de la primera parte de la dirección, junto con un website "secreto"(secret)

moodle_process_email() - cualquier proceso de correo que no corresponde a ningún módulo va aquí( generalmente utilizado para procesar rebotes(bounces))

Nuevos archivos:

admin/process_email.php

Este script necesita ser llamado desde su MTA por algo que comience con el prefijo de 3 caracteres descrito anteriormente( y opcionalmente, la dirección noreply(sin respuesta)).

Cómo funciona? Penetra y descodifica la dirección de correo en id de módulo(moduleid) y valida half md5 hash, y llama a $modname_process_email (si existe). Estas funciones tienen como argumentos: $modargs (alguna parte de la dirección de correo que no es ni el prefijo, ni el id de módulo ni el hash) y el contenido del correo (leído desde STDIN).

Se duplica como el autorresponder a dirección sin respuesta( noreplyaddress) si lo configura como que esa dirección es válida. Respondiendo con un mensaje amigable: "this is not a real email address"(no es una dirección de correo válida).

Creadores de Módulos

Eche una mirada a las funciones nuevas moodle_process_email() y generate_email_processing_address() en el archivo moodlelib.php para idéas acerca de cómo

codificar y decodificar los argumentos que su módulo necesita para realizar el proceso
trabajar con múltiples "acciones"("actions") para un módulo concreto.

En resumidas cuentas, los usuarios pueden enviar correo a Moodle utilizando direcciones dinámicas especiales. Estos correos puedel lanzar(trigger) una llamada a una función módulo de esta forma nombremodulo_process_email($str, $cuerpodeemail). La parte $str constará de hasta 42 caracteres de datos, generados por Moodle( razonadamente por su propio módulo), y la parte $cuerpodeemail es el contenido del correo( obtenido leyendo la entrada estándar STDIN - generado normalmente por los usuarios MUA).

Los 42 caracteres provienen de la "parte local"(local part) de una dirección de correo( lo anterior al signo @) que puede tener hasta 64 caracteres. De esos 64 caracteres, Moodle utiliza 22, dejándole 42 caracteres para codificar datos.

Qué hace Moodle con los 22 caracteres? Cuatro para el prefijo, ya que necesita permitir a MTA saber cómo pasar el mensaje a su script. Dos para el identificador de módulo (ID) y así sabrá para qué módulo se generó el mensaje( y así enviar la petición al módulo). Los 16 caracteres restantes son la firma (HMAC-MD5-8) utilizada para autentificar el mensaje.

Cuarenta y dos caracteres no es mucho (aunque podrían ser la respuesta de su vida, el universo, todo!) asegúrese de utilizarlos con sabiduría.

La forma más eficiente de codificar identificadores(IDs), en bases de datos es su rango completo (y así puedan situarse en una dirección de correo), que hemos encontrado es base64_encode(pack('V',2147483647)), que devuelve "/ / / / f w = =". Los dos caracteres( o la cadena entre ellos) "= =" son redundantes y puede borrarles (necesitará reañadirles cuando recupere sus datos). Encadene sus parámetros como IDs codificadas en celdas(slots) posicionales por efectividad.

Para recuperar sus datos, utilice substr() para separar los parámetros, y entonces desempaquételos(unpack)('V',base64_decode($str)). Dese cuenta que devolverá una matriz(array) de un elemento.

Nota: Utilizando 'V' alcanza 2147483647, la mitad del rango de un INT en mySQL. Además, 'V' se comporta como un valor con signo, más bien que sin signo, así pues sospecho que hay un bug en la documentación PHP de pack().

Con cada ID tomamos 6 caracteres (8 si encontramos la forma de utilizar el rango completo de 'V'), tiene un número limitado de parámetros. Si necesita codificar más información, almacénela en la BD y envíe correos que enlacen sus datos almacenados. Recuerde borrar esos datos temporales después de un periodo de tiempo prudencial.

Nota: No intente utilizar codificación de ancho de variable(variable-width)en sus IDs, funciona en pequeñas instalaciones, pero falla en las grandes.

Términos de Seguridad

Cualquier código en nombremodulo_process_email() debe suponer que verá respuestas repetidas y manejarlas con garbo. La definición de con garbo(gracefully) depende de lo que realice el código.

Algunas veces los servidores de correo (MTAs) re-transmitirán un mensaje si no están seguros de que el MTA receptor lo ha recibido -- y algunas veces sysadmins puede repetir(replay) una cola de correo entera si algo ha ido mal. En ese caso, los cuerpos del correo serán idénticos, las cabeceras ligeramente diferentes.

Un caso diferente, el usuario puede contestar(reply) el mensaje dos veces. Quizás por error, quizás a propósito. Qué hacer depende del contexto específico.

Usted /podría/ apoyar mejor protección al nivel de entorno de trabajo(framework), manteniendo la pista de cada dirección de respuesta que envía. Estamos en contra de esta opción por (a) el impacto en la ejecución sería importante y (b) queremos que el primero destaque y sea simple de cambiar en caso de necesidad.

Con esto la implementación inicial, los módulos deberían poseer funciones que manejasen esos casos de "repeticiones"("replay") correctamente. Si quiere añadir funciones adicionales, puede añadir "seguimiento"("tracking") como opción posteriormente. Sería horrible tener cruzados todos los correos enviados desde Moodle.

Documentation