¿Por qué postfix entregó una notificación de rebote a un archivo spool local, cuando la entrega a este usuario se ha deshabilitado?

¿Por qué postfix entregó una notificación de rebote a un archivo spool local, cuando la entrega a este usuario se ha deshabilitado?

Mi configuración de postfix permite el correo a través de varios local_recipient_maps. Sin embargo, la entrega a "proxy:unix:passwd.byname" es específicamentedesactivado. Esto normalmente impide la entrega a usuarios locales de Unix:

$ getent passwd | grep www-data
www-data:x:33:33:www-data:/var/www:/bin/sh
$ nc localhost 25
220 my.mail.host ESMTP Postfix
helo localhost
250 my.mail.host
mail from:[email protected]
250 2.1.0 Ok
rcpt to:[email protected]
550 5.1.1 <[email protected]>: Recipient address rejected: User unknown in local recipient table
rcpt to:www-data
550 5.1.1 <www-data>: Recipient address rejected: User unknown in local recipient table

Sin embargo, esta mañana noté un correo electrónico entregado al archivo de cola de correo www-data local. Mirando hacia dentro veo que:

  • fue un mensajede [correo electrónico protegido], enviado por un host diferente dentro de nuestra red, utilizando my.mail.host como host inteligente
  • Permaneció en la cola my.mail.host durante varios días mientras intentaba reintentar
  • Luego rebotó
  • El rebote se entregó a un archivo de cola de correo "www-data" en my.mail.host

Entonces mi pregunta es:¿Por qué sucedió esto y cómo puedo evitar que suceda en el futuro?

Respuesta1

Suposición

Usted dijo

la entrega a "proxy:unix:passwd.byname" está específicamente deshabilitada. Esto normalmente impide la entrega a usuarios locales de Unix.

Por lo tanto, puedo suponer que eliminas las partes proxy:unix:passwd.byname de local_recipient_maps. Por defecto el valor de este parámetro es

# postconf -d local_recipient_maps
local_recipient_maps = proxy:unix:passwd.byname $alias_maps

Y lo cambias a

# postconf local_recipient_maps
local_recipient_maps = $alias_maps

Análisis

Entonces, ¿por qué rechaza el correo normal pero sigue rebotando el correo?

Para responderla, necesitamos ver el panorama general deDescripción general de la arquitectura Postfix, especialmente cuando postfix recibe un correo electrónico

                            trivial-
                           rewrite(8)
Network ->  smtpd(8)           |  ^    
                       \       v  |
Network ->  qmqpd(8)    ->  cleanup(8)  ->  incoming
                       /
            pickup(8)   <-  maildrop
                                ^
                                |
Local   ->  sendmail(1) ->  postdrop(1)

Postfix sólo consulta local_recipient_mapscuando verifica el correo electrónico recibido a través de smtpd. ¿Por qué? Porque las comprobaciones se realizaron cuando smtpd_reject_unlisted_recipientel valor del parámetro es 'sí' o lo configuró reject_unlisted_recipienten smtpd_*_restrictions (observe la palabra smtpd en el nombre de ambos parámetros). Verhombre posconferenciapara detalles del parámetro. Esta verificación está habilitada de forma predeterminada. Eso explica por qué postfix rechazó su correo electrónico de prueba.

Rebotares un correo electrónico especial en la arquitectura postfix. Se generó internamente mediante postfix para informar el informe de estado de (no) entrega al remitente. Fluyea través de postfix directamente a la limpieza, evitando smtpd. Por eso www-datatodavía recibo correos electrónicos rebotados.

Solución

En lugar de rechazarlo, puedes enviarlo al agujero negro conmapas_transporte_buzónydesecharservicio.

Para hacer esto, configure mailbox_transport_maps

#main.cf
mailbox_transport_maps = hash:/etc/postfix/wwwdata-blackhole

#/etc/postfix/wwwdata-blackhole
www-data   discard:silently

Ahora, cada vez que www-data reciba un correo electrónico, lo descartará silenciosamente.

información relacionada