6

We run a small postfix (and dovecot) mail server for a number of hosted domains, using virtual alias maps and with spamassassin configured.

Recently it's become apparent that we're generating some backscatter; spam emails are coming into non-existant email addresses and they are being bounced back to the forged sender. This is obviously a problem in terms of reputation for our mail server and also means we're spamming on behalf of the spammers.

What I want to do then is change the postfix behaviour so that, instead of generating a bounce email form MAILER-DAEMON the mail is rejected during the SMTP transaction.

I've tried adding local_recipient_maps (http://www.postfix.org/LOCAL_RECIPIENT_README.html), but this made no difference. I think this is because I'm using virtual_alias_maps (and other virtual mailbox solutions don't seem to apply here either).

postconf -n generates:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5
html_directory = no
inet_interfaces = all
inet_protocols = all
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
mail_owner = postfix
mail_spool_directory = /var/spool/mail
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 0
mydestination = $myhostname, localhost.$mydomain, localhost
mydomain = verrotech.com
myhostname = mail.verrotech.com
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES
sample_directory = /usr/share/doc/postfix-2.10.1/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.domain.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.domain.com/privkey.pem
smtpd_tls_security_level = may
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual

Thank you.

Improve this question
7
  • 2
    I'm confident that you already read the official doc about backscatter. If it didn't work, probably you've issues in your config. As a first line of troubleshooting, please, confirm that your setup is a "separate domains, UNIX system accounts". If yes, than probably the missing virtual_alias_domains (whose defaults help your postfix running correctly) may raise some problems. Also, log-lines related to inbound email and outgoing bounce, could help us understanding :-)
    – Damiano Verzulli
    Jul 31, 2016 at 21:34
  • Indeed I have though that doc is about filtering out backscatter being received, not about it being sent (my problem). I don't need virtual_alias_domains it seems as I use DOMAIN Enable lines in /etc/postfix/virtual - but I will have a look at naming these specifically. The actual bouncing is fine and correct, it's just I want to reject at the SMTP stage rather than generating a bounce message from MAILER-DAEMON so I don't think the logs can show anything useful at all, but I'll have a look at those as well, thanks.
    – Dave
    Aug 1, 2016 at 13:32
  • You wrote: "...spam emails are coming into non-existant email addresses and they are being bounced back to the forged sender...", and in the documentation I pointed above, I read: "How do I block backscatter mail to random recipient addresses? If your machine receives backscatter mail to random addresses, configure Postfix to reject all mail for non-existent recipients as described in [...]". Am I missing something?
    – Damiano Verzulli
    Aug 1, 2016 at 15:40
  • "If your machine receives backscatter mail to random addresses" - my machine is not receiving backscatter mail, it is generating it. I appreciate the solutions to unknown recipients may be the same (SMTP reject), but I've implemented the solutions and they are generating bounces, not an SMTP reject. So beyond the (not working) solution to use unknown_local_recipient_reject_code (see my postconf in the question) this document doesn't seem to help, as the other filters are not applicable. Thanks.
    – Dave
    Aug 1, 2016 at 18:20
  • Ok, let's forget about the word "backscatter" for a second. If I say this: a remote spammer is sending mail to a fake [email protected] using a forged "from" [email protected]; as [email protected] is an unknown local recipient, you're currently sending to [email protected] a "bounce" for a message she never sent. So, you're going to reconfigure your postfix instance so that when it receive a message for [email protected], it refuse the message at SMTP level, without queuing it and... without generating the bounce. Am I right?
    – Damiano Verzulli
    Aug 1, 2016 at 20:30

2 Answers 2

Reset to default
9
+50

After some research, your question made me realize that I had the same problem in my mail server, so first of all, thanx.

Second, you should note that, by default, postfix blocks this kind of traffic. In the manual smtpd_reject_unlisted_recipient:

smtpd_reject_unlisted_recipient (default: yes)

Request that the Postfix SMTP server rejects mail for unknown recipient addresses, even when no explicit reject_unlisted_recipient access restriction is specified. This prevents the Postfix queue from filling up with undeliverable MAILER-DAEMON messages.

So, why are you getting 250 OK for unknown destination mails? Because of these lines:

mydestination = $myhostname, localhost.$mydomain, localhost
virtual_alias_maps = hash:/etc/postfix/virtual

The smtpd_reject_unlisted_recipient checks destination mails but very specifically:

An address is always considered "known" when it matches a virtual(5) alias or a canonical(5) mapping.

   The recipient domain matches $mydestination, $inet_interfaces or $proxy_interfaces, but the recipient is not listed in $local_recipient_maps, and $local_recipient_maps is not null.
   The recipient domain matches $virtual_alias_domains but the recipient is not listed in $virtual_alias_maps.
   The recipient domain matches $virtual_mailbox_domains but the recipient is not listed in $virtual_mailbox_maps, and $virtual_mailbox_maps is not null.
   The recipient domain matches $relay_domains but the recipient is not listed in $relay_recipient_maps, and $relay_recipient_maps is not null.

As your mydestination does not include your $mydomain (only the servername and localhost) and you do not have any *_domains in place, there are no other checks for "known" destinations.

You only need to add:

virtual_alias_domains = $mydomain

an reload postfix. (If I'm getting your config right and all your mail are in the form "[email protected]")

If that does not work, you might try this:

smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unverified_recipient

NOTE: it will check via RCPT TO command if the destination trully exists for both incoming and outgoing messages. Use with caution since it makes an extra connection for each new destination and will take some time to respond to every mail your server processes (It can take a few seconds to test each destination).

Improve this answer
6
  • 1
    I second this answer (I mentioned myself about the missing virtual_alias_domains directive, in comment above), even if based on the official documentation I see that virtual_alias_domains default value is $virtual_alias_maps (that is present in the config snippet of the OP). Nevertheless, again, this sounds definitely like something to try.
    – Damiano Verzulli
    Aug 1, 2016 at 20:39
  • Sorry, I didn't read the comment. I actually fixed my own postfix since I only did virtual_aliases but had mydestination=$mydomain (had to empty that and I think that fixed my config, but I did also create the _domains). Would you prefer that I delete this answer since it is basically your comment?
    – NuTTyX
    Aug 1, 2016 at 20:55
  • no problem at all! Your answer is better than my comment so... it's ok :-)
    – Damiano Verzulli
    Aug 1, 2016 at 21:01
  • Hi, thanks for your suggestion. I don't need virtual_alias_domains as they are enabled in virtual. From VIRTUAL(5): "Besides virtual aliases, the virtual alias table can also be used to implement virtual alias domains. With a virtual alias domain, all recipient addresses are aliased to addresses in other domains....". Just to be sure I did add the virtual_alias_domains line and it made no difference. Removing the mydestination values (mydestination=) just led to ALL mail bouncing (mail for mail.domain.com loops back to myself), because the alias maps user@domain to [email protected]
    – Dave
    Aug 2, 2016 at 8:40
  • As for reject_unverified_recipient I'd prefer not to use this for the reasons you list and I'm sure I shouldn't need to; postfix IS bouncing the mail correctly, all I want it to do is reject it at the SMTP stage (seems so simple, but apparently not!). Any help much appreciated.
    – Dave
    Aug 2, 2016 at 8:41
3

This answer isn't exactly what you asked for, but this is how I solved that problem for my own use cases.

Discarding Bounces:

In /etc/postfix/main.cfg, I have:

2bounce_notice_recipient = devnull
bounce_notice_recipient = devnull
bounce_queue_lifetime = 0d
delay_warning_time = 0h
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases

In /etc/postfix/aliases, I have:

devnull:    /dev/null

Then I run:

postmap aliases
postfix reload

The end result is that bounces go to /dev/null. It may not catch all of them, so YMMV. Please let me know if this works for you.

Improve this answer
3
  • Thanks for this. As you say not exactly what I'm after but thanks for the devnull pointer. My concern here is that (a) bounces then won't get anything back (a genuine bounce would give an error to someone if the SMTP process returns 550), and (b) my users send through authenticated SMTP, I still want them to get bounce messages back (e.g. my server connects and is rejected, or can't lookup the MX etc) - I imagine those also go into the devnull as bounce notices.
    – Dave
    Jul 29, 2016 at 10:59
  • You're welcome. Yes, this could cause problems for people relaying through your host with their MUA. In my case, it was java and perl creating the emails and it wouldn't know what to do with bounces, much less be able to process them. The user would never see those anyway. They were just clogging up my queues.
    – Aaron
    Jul 29, 2016 at 18:54
  • 1
    devnull: /dev/null trick does not seem to work if you have virtual aliases.
    – teknopaul
    Mar 17, 2018 at 23:43

You must log in to answer this question.

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