2

The topic of handling bounce message for remote rejects has been brought up at least three times (1, 2, 3), and it looks as if there is no real solution. I wonder, though, if the bounce template can be modified to not include the reject message from the remote server (which contains information about the final recipient address I would rather not send to a spammer).

Thanks in advance for any hint, Jan

PS. I cannot find the default bounce template on Ubuntu 20.04 (it's not in /etc/postfix nor anywhere else). How are the DSN created without a (default) template file?

1 Answer 1

0

You don't send bounce message to "spammers" at all. Actually you can't, because you don't know who the spammer really is and where to send the bounce. The "MAIL FROM" envelope address is likely forged; if it is deliverable, the person which uses that address is an innocent victim.

If you send them a "bounce message" they will be surprised, because they didn't sent anything to you, and then annoyed, because your bounce message now is a unsolicited message to them. In other words, by trying to "send bounce messages to spammers", you became a spammer yourself. This is called a backscatter. Don't turn into a backscatter!

Bounces are generated for queued mail which can't be delivered further. What you should do instead tweaking a bounce behaviour is not to queue any messages from spammers, so you don't even need to generate bounces. For that, you have to reject as early as you could, which implies the use of before-queue mail filtering, e.g. the filtering which happens during live SMTP session, and you usually reject after either RCPT or DATA command.

Then the system which tries to deliver mail to your server is responsible of generating bounces. If that was a legitimate server, it is usually associated with the real sender somehow (e.g. they probably authenticated the sender) so they will be sure they send bounce to where is belogns; if that was spammer, that is not your problem anyway.

This is what Postfix tries to do by default (for instance, read LOCAL_RECIPIENT_README, which explains why you have to reject unknown recipients early and warns that you become a backscatter if you don't), and I feel I gave a good reason to keep it like that. It has a manual on that. Also, as it is said there, milter could give you similar effect, and I personally prefer the milter way.


A default bounce template exists in the Postfix source at least. Your distribution may have it installed in the /usr/share/postfix... or /usr/share/doc/postfix..., or may not. The procedure of altering the template is described in the manual too.

Note that the bounce message must have the complete recipient information. The purpose of the bounce message is to inform sender so they may debug the situation or take some other measures if the problem is not on their side, for instance, notify the postmaster of problematic site about the problem. For this to be successful they must be presented with all relevant technical information, and the default bounce template has actually the minimum required set. So you shouldn't reduce the information appeared there. I altered bounce templates on my servers, for example, to translate them into local language and to add an information on how to call the server tech support. This has nothing to do with privacy.

3
  • 1
    Thanks! I obviously would prefer to reject all fraudulent messages in the first place, but for some messages, the final recipient server has stricter rules than my server. In these cases, I cannot prevent the generation of a (remote) bounce message, and this message is in turn included in my server's bounce message, thus revealing a line in my virtual_alias_map.
    – janeden
    Jan 29, 2022 at 21:10
  • 1
    This answer just ignores the problem. Anyone who tries to use Postfix as mail forwarder will have the problem of the upstream server rejecting a message. "You must not backscatter", "you must not disable bounce", "you must provide complete recipient information" etc. doesn't help at all.
    – AlexVB
    Sep 11, 2023 at 18:58
  • Well, "the problem" here is a false problem to solve, and answer explains precisely that. People often have their fantasies about how things work, unfortunately these don't correlate with the reality. This happens with email quite often on this site. You probably have one too. Reality of the email is known from reading RFCs, software documentation and a long time experience. If you have a server that forwards email on behalf of complete strangers, to the point you don't want to show them where they attempted to send mail and why it failed, you have a much bigger problem than bounce templates. Sep 12, 2023 at 3:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .