У меня есть сервер Postfix, который принимает почту для виртуальных псевдонимов и пересылает их на реальные адреса назначения. Когда последний почтовый сервер возвращает ошибку, сообщение о недоставке, возвращаемое отправителю, показывает адрес электронной почты конечного получателя. Например. если мой сервер получает почту для fake@forwarding.address.com и безуспешно пытается отправить ее на the@real.address.com, сообщение об отказе выглядит примерно так:
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<the@real.address.com> (expanded from <fake@forwarding.address.com>): host
final.mail.host.com said: 553 5.1.8
<the@real.address.com>... <some error> (in reply to RCPT TO command)
Как мне не дать ему раскрыть окончательный адрес?
Догадаться. Вам нужно убедиться, что письмо отклонено, а не возвращено, а также установить unverified_recipient_reject_reason чтобы избежать раскрытия истинного сообщения. Я пробовал это раньше, но фокус был в порядке пунктов в smtpd_recipient_restrictions:
smtpd_recipient_restrictions = reject_unknown_recipient_domain, reject_unverified_recipient, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
unverified_recipient_reject_reason = Recipient address verification failed
У меня раньше было два разрешать ограничения до reject_unverified_recipient, поэтому они обрабатывались в первую очередь, а почта от любых местных или аутентифицированных отправителей не подлежала проверке адреса получателя. Он потерпел неудачу только позже, после того, как был принят, и сгенерировал сообщение об отказе.
Это все еще не идеально, потому что последний MTA может отправить сообщение о недоставке исходному отправителю, но с этим ничего не поделать. Соответствующая ветка списка рассылки Postfix: http://tech.groups.yahoo.com/group/postfix-users/message/251715