[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [postfix] Añadir cabecera a una copia creada con recipient_bcc_maps



El Sun, 30 de Aug de 2015, a las 01:39:36PM +0000, Camaleón dijo:

> ¿Te refieres a las prioridades que tienen? No, en ese RFC no lo veo, debe 
> de estar definido en algún otro pero estar está porque tuve que 
> consultarlo en su día. 

En ese mismo RFC dice:

When the "Reply-To:" field is present, it indicates the mailbox(es) to
which the author of the message suggests that replies be sent

Eso no implica obligatoriedad ciertamente. No sé, he procurado buscar,
pero no he encontrado nada al respecto. Bueno, sí. En el RFC 822 al que
derogó precisamebnte el 2822. En ese sí que queda claro que hay que usar
el campo de Reply-To:

For systems which automatically  generate  address  lists  for replies
to messages, the following recommendations are made:

[...]

 - If the "Reply-To" field exists, then the reply should go to the
   addresses indicated in that field and not to the address(es)
   indicated in the "From" field.

> Ya, lo que te quiero decir es que en cualquier caso no depende de ti ni 
> de las reglas que generes ni cómo las generes sino del cliente de correo 
> que es, al fin y al cabo, quien va a responder al mensaje con la cabecera 
> alterada. Los clientes más puristas (como dices, Mutt o Pine, 
> Thunderbird...) lo respetarán pero es posible que otros no lo hagan, 
> generalmente los webmail que van a su bola.

En realidad, es sólo un "servicio adicional" para el despistado: yo lo
soy, por ejemplo. No es algo esencial.

>> No. Hay dos directivas: header_checks y smtp_header_checks. La primera
>> opera sobre los correos que recibe el servidor y, por tanto, afectaría a
>> ambos mensajes tal como tú dices. En cambio smtp_header_checks opera
>> sobre los correos salientes. Como la única copia del mensaje que vuelve
>> a salir es la que tiene como destino la cuenta remota, sólo es esta la
>> que se ve afectada por la adición del campo Reply-To.
> 
> Hum... yo entiendo que Postfix te creará dos mensajes, una para el 
> destinatario original y otra para el destinatario desdoblado, 
> independientemente de dónde deje Postfix los correos, salvo que el 
> destino final sea un buzón propio de Postfix (p. ej., "/var/mail/") y no 
> tenga que dar más "saltos". Pero ya te digo, hay que probarlo.

No, estás confundiendo header_checks con smtp_header_checks. La segunda
sólo se aplica a los mensajes que, desde postfix, salen con dirección a
otro servidor de correo. Como de los dos mensajes que se generan sólo el
"rebotado" vuelve a salir (el otro va a un buzón),sólo él sufre el cambio.

En realidad, podrían sufrir el cambio todos los mensajes salientes,
rebotados o no. Lo que ocurre es que los mensajes salientes no tienen
nunca como dominio de correo el propio dominio de la máquina. A menos
que reboten, claro. No se me ocurre otro caso.

El problema de todo esto es lo limitado de los filtros que permite
smtp_header_checks (y header_checks por su lado).

>> Porque creo que no sirven más que para agilizar un poco las
>> comprobaciones: dentro del if "condicion" sólo se pueden hacer
>> comprobaciones adicionales sobre el campo que se usó para formar la
>> condición.
> 
> Yo creo que no, ya que de lo contrario los filtros serían muy limitados.

Es que son muy limitados. Ya te digo yo que es así: hay unos cuantos
mensajes en foros en los que el fallo de que una configuración no
funcione es precisamente esa creencia. De hecho, en los ejemplos de la
documentación siempre se cumple lo que digo. Es más, si fuera como
dices, ¿qué sentido tendría que la sintaxis de las comprobaciones
manuales sea así?:

# postmap -q 'To: etc...' regexp:/etc/postfix/fichero_con_filtros

Habría que pasar todo el mensaje si se pudieran combinar varias
cabeceras para crear un filtro.

Dentro de mis limitaciones con postfix, creo haber dado con una solución
mejor: usar un transporte. Lo defino así en master.cf

#v+
rebote  unix  -       n       n       -       -       pipe
   flags=XR user=vuser argv=/usr/local/bin/rebote.sh ${recipient}
#v-

Y en main.cf defino un par de mapeos:

recipient_bcc_maps = hash:/etc/postfix/recipient-bcc
transport_maps = regexp:/etc/postfix/rebotes

El primero sirve para indicar qué destinatarios tienen definido un
rebote y a qué cuenta. Por ejemplo:

usuario_local@example.org    rebote--usuario_remote@gmail.com

Ese "rebote--" es el que indica que quiero usar el transporte, de lo
contrario, el rebote se produciría sin más y el mensaje rebotado no
sufrirá cambios.

El segundo mapeo es, precisamente, para indicar que las direcciones que
empiezan por "rebote--" usan el transporte:

/rebote--.*/     rebote

Por último, el transporte es este:

#v+
#!/bin/sh
formail -i 'Reply-To: "Destinatario no original" <no-reply@nowhere.com>' \
   | /usr/sbin/sendmail -oi ${1#*--}
#v-

O sea, formail coge el mensaje original, le añade un campo Reply-To y,
si había ya uno, lo renombra a Old-Reply-To. El mensaje así modificado,
se envía a la dirección deseada (eliminando el "rebote--" claro).

Adicionalmente, se podría modificar el cuerpo para que al principio
incluyera una leyenda recordatoria.

Posiblemente no sea muy eficiente usar este script de bash, pero apenas
hay correos y carga de trabajo, así que no es problema.

Un saludo.

-- 
   El más seguro bien de la fortuna
es no haber tenido vez alguna.
                  --- Alonso de Ercilla ---


Reply to: