5

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.

Dave
  • 345
  • 1
  • 2
  • 12
  • 2
    I'm confident that you already read the [official doc](http://www.postfix.org/BACKSCATTER_README.html#random) 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"](http://www.postfix.org/VIRTUAL_README.html#virtual_alias). 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 '16 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 01 '16 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 01 '16 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 01 '16 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 _X@yourdomain.com_ using a forged "from" _Z@another.domain.com_; as _X@yourdomain.com_ is an unknown local recipient, you're currently sending to _Z@another.domain.com_ 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 _X@yourdomain.com_, it **refuse** the message at SMTP level, without queuing it and... without generating the bounce. Am I right? – Damiano Verzulli Aug 01 '16 at 20:30
  • Yes that's correct. As I say though I've followed the relevant parts of reject mail for unknown recipients documentation. It bounces ok, just doesn't reject. – Dave Aug 02 '16 at 08:35
  • Thank you Damiano but see my comment below - I've found the root cause (and it was in my virtual file!). Thanks so much for your input, but this now explains why the config was correct and changing it doesn't affect anything. – Dave Aug 02 '16 at 09:04

2 Answers2

8

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 "user@domain.com")

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).

NuTTyX
  • 1,128
  • 5
  • 10
  • 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](http://www.postfix.org/postconf.5.html#virtual_alias_domains) 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 01 '16 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 01 '16 at 20:55
  • no problem at all! Your answer is better than my comment so... it's ok :-) – Damiano Verzulli Aug 01 '16 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 alias@mail.domain.com – Dave Aug 02 '16 at 08: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 02 '16 at 08:41
  • Right so it turns out I'm an idiot - the problem wasn't the postfix config as such - the bouncing WAS working. When I delved deeper into the virtual file I found "@domain.com error:nouser Mailbox Not Found" lines. These seem to date from legacy sendmail configuration. Once removed the mail is rejected at the SMTP level (of course until then there was a matching line). Just using virtual_alias_maps with all the config works fine. I'll accept this answer and bounty it in case anyone is having similar problems (but is less of an idiot than me!). – Dave Aug 02 '16 at 09:02
2

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.

Aaron
  • 2,809
  • 2
  • 11
  • 29
  • 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 '16 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 '16 at 18:54
  • 1
    devnull: /dev/null trick does not seem to work if you have virtual aliases. – teknopaul Mar 17 '18 at 23:43