Re: [postfix] Añadir cabecera a una copia creada con recipient_bcc_maps
El Mon, 31 Aug 2015 11:45:26 +0200, José Miguel (sio2) escribió:
> 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.
Ya me di cuenta del "suggest", vamos, que es una sugerencia que el
cliente de correo puede usar como dirección de respuesta pero no de
obligado cumplimiento. Como digo, lo mejor es probarlo desde el propio
cliente que se va a usar para ver cómo lo interpreta.
> 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.
Pero eso es los sistemas automáticos (p. ej., listas de correo), no para
los mensajes punto a punto.
>> 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, si no me parece mala idea. Yo hago lo mismo en esta lista (no tienes
más que ver en la cabecera de este correo el campo "Reply-To").
>>> 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.
Cómo actúe el "smtp_header_checks" dependerá de la configuración de la
entrega de mensajes que tengas en el servidor de correo, pero si dices
que los mensajes para el destinatario original se quedan en el propio
servidor (agente de entrega local/virtual) y no los gestiona smtp/lmtp
(p. ej., cuando los pasas a Dovecot o Cyrus) entonces sí.
> 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).
Si los filtros estándar se quedan cortos podrías pasarlo a otro
analizador, como Amavisd-New, MIMEDefang o Milter. Algún sistema que te
permita mayor control sobre la edición de las cabeceras de los mensajes.
>>> 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.
Comprobaría si el campo "To: [...]" aparece en la cabecera del mensaje y
en ese caso ejecutaría las acciones determinadas en "fichero_con_filtros"
independientemente de dónde se encuentren en la cabecera. Si eso no es
posible será por una mera limitación de Postfix pero no porque sea
inviable.
> Dentro de mis limitaciones con postfix, creo haber dado con una solución
> mejor: usar un transporte.
En principio no veo cómo con definir un transporte "sin más" vas a poder
alterar la cabecera de un correo.
> 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).
Ah, eso sí podría funcionar.
Es como pasarle el mensaje a otro servicio (Amavisd-New, MIMEDefang...)
para que lo analice y haga lo que tenga que hacer (añada cabeceras, quite
adjuntos, etc...) y luego lo devuelve a Postfix para que lo envíe. En
este caso, el script (veo que es de procmail) haría el trabajo de
reemplazar el campo.
> 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.
Bueno, tiene que ejecutarse para cada uno de los correos de salida, así
que la penalización en el rendimiento de tu servidor dependerá de la
carga de trabajo que tengas en Postfix.
Saludos,
--
Camaleón
Reply to: