[GH-ISSUE #1416] Reject unknown recipient addresses #1123

Closed
opened 2026-02-27 11:15:24 +03:00 by kerem · 17 comments
Owner

Originally created by @skandragon on GitHub (Mar 3, 2018).
Original GitHub issue: https://github.com/modoboa/modoboa/issues/1416

Impacted versions

  • Modoboa: 1.10.3
  • installer used: Yes (then upgraded recently)
  • Webserver: Nginx

For some reason, my quarantine list is littered with email destinations that do not exist, and have never existed in this modoboa setup.

How do I have addresses that will never work rejected at the SMTP layer, so they just bounce back, rather than end up in my quarantine list? Ideally, this should be possible to do through the UI; I know I can just manually configure postfix, but it should do this out of the box.

Originally created by @skandragon on GitHub (Mar 3, 2018). Original GitHub issue: https://github.com/modoboa/modoboa/issues/1416 # Impacted versions * Modoboa: 1.10.3 * installer used: Yes (then upgraded recently) * Webserver: Nginx For some reason, my quarantine list is littered with email destinations that do not exist, and have never existed in this modoboa setup. How do I have addresses that will never work rejected at the SMTP layer, so they just bounce back, rather than end up in my quarantine list? Ideally, this should be possible to do through the UI; I know I can just manually configure postfix, but it should do this out of the box.
kerem 2026-02-27 11:15:24 +03:00
Author
Owner

@ghost commented on GitHub (Mar 3, 2018):

It's part of the Postfix configuration.

smtpd_recipient_restrictions =
      # ...
      check_recipient_access
          <driver>:/etc/postfix/sql-maintain.cf
          <driver>:/etc/postfix/sql-relay-recipient-verification.cf
      permit_mynetworks
      reject_unauth_destination
      reject_unverified_recipient
      # ...

The important two being reject_unauth_destination and reject_unverified_recipient, check this is set in main.cf.

If you've used the installer this should be set for you, have you made any changes to main.cf? If you're still having issues post a copy of main.cf.

<!-- gh-comment-id:370146504 --> @ghost commented on GitHub (Mar 3, 2018): It's part of the [Postfix configuration](http://modoboa.readthedocs.io/en/latest/manual_installation/postfix.html#configuration). ``` smtpd_recipient_restrictions = # ... check_recipient_access <driver>:/etc/postfix/sql-maintain.cf <driver>:/etc/postfix/sql-relay-recipient-verification.cf permit_mynetworks reject_unauth_destination reject_unverified_recipient # ... ``` The important two being [reject_unauth_destination](http://www.postfix.org/postconf.5.html#reject_unauth_destination) and [reject_unverified_recipient](http://www.postfix.org/postconf.5.html#reject_unverified_recipient), check this is set in `main.cf`. If you've used the installer this should be set for you, have you made any changes to `main.cf`? If you're still having issues post a copy of `main.cf`.
Author
Owner

@skandragon commented on GitHub (Mar 3, 2018):

No, but I think I realized I left the domain set up to relay unknown users to a second host, and that relay is what is currently causing the spam filtering to kick in before sending it along. I think once I remove that, it should work as expected.

<!-- gh-comment-id:370147030 --> @skandragon commented on GitHub (Mar 3, 2018): No, but I think I realized I left the domain set up to relay unknown users to a second host, and that relay is what is currently causing the spam filtering to kick in before sending it along. I think once I remove that, it should work as expected.
Author
Owner

@skandragon commented on GitHub (Mar 4, 2018):

I was in transition, where I was moving accounts from the old server to the new one bit by bit. However, they are all moved, and I changed the domain flame.org from a relay domain to a plain old domain. I expected this to start causing unknown addresses to be rejected, however, I see one in the quarantine that is not a valid address.

Here's the relevant part of the config:

# Recipient restriction rules
smtpd_recipient_restrictions =
      permit_mynetworks
      permit_sasl_authenticated
      check_recipient_access
          proxy:pgsql:/etc/postfix/sql-maintain.cf
          proxy:pgsql:/etc/postfix/sql-relay-recipient-verification.cf
      reject_unverified_recipient
      reject_unauth_destination
      reject_non_fqdn_sender
      reject_non_fqdn_recipient
      reject_non_fqdn_helo_hostname
<!-- gh-comment-id:370203909 --> @skandragon commented on GitHub (Mar 4, 2018): I was in transition, where I was moving accounts from the old server to the new one bit by bit. However, they are all moved, and I changed the domain `flame.org` from a relay domain to a plain old domain. I expected this to start causing unknown addresses to be rejected, however, I see one in the quarantine that is not a valid address. Here's the relevant part of the config: ``` # Recipient restriction rules smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated check_recipient_access proxy:pgsql:/etc/postfix/sql-maintain.cf proxy:pgsql:/etc/postfix/sql-relay-recipient-verification.cf reject_unverified_recipient reject_unauth_destination reject_non_fqdn_sender reject_non_fqdn_recipient reject_non_fqdn_helo_hostname ```
Author
Owner

@skandragon commented on GitHub (Mar 4, 2018):

More info, here are the logs dealing with this specific spam.

Note that I am using postscreen, which I think is set up automatically.

Mar  4 05:19:47 postmark postfix/lmtp[10386]: 530A0840917: to=<magic@flame.org>, relay=postmark.flame.org[private/dovecot-lmtp], delay=0.03, delays=0/0.01/0.01/0.01, dsn=5.1.1, status=undeliverable (host postmark.flame.org[private/dovecot-lmtp] said: 550 5.1.1 <magic@flame.org> User doesn't exist: magic@flame.org (in reply to RCPT TO command))
Mar  4 05:19:51 postmark amavis[2652]: (02652-03) Blocked SPAM {DiscardedInbound,Quarantined}, [104.47.32.220]:51712 [41.113.167.214] <> -> <magic@flame.org>, quarantine: nF3hoWyr2q8z, Message-ID: <201803040520.w2453hAe025317@efectiva.com.pe>, mail_id: nF3hoWyr2q8z, Hits: 20.356, size: 20671, dkim_sd=selector1-efectiva-com-pe:efectivasa.onmicrosoft.com, 2168 ms
Mar  4 05:19:51 postmark postfix/smtpd[10384]: proxy-accept: END-OF-MESSAGE: 250 2.7.0 Ok, discarded, id=02652-03 - spam; from=<> to=<magic@flame.org> proto=ESMTP helo=<NAM01-SN1-obe.outbound.protection.outlook.com>

What's strange here is that the message looks like it's rejected, but then is passed through amavis, which quarantines it.

<!-- gh-comment-id:370204837 --> @skandragon commented on GitHub (Mar 4, 2018): More info, here are the logs dealing with this specific spam. Note that I am using postscreen, which I think is set up automatically. ``` Mar 4 05:19:47 postmark postfix/lmtp[10386]: 530A0840917: to=<magic@flame.org>, relay=postmark.flame.org[private/dovecot-lmtp], delay=0.03, delays=0/0.01/0.01/0.01, dsn=5.1.1, status=undeliverable (host postmark.flame.org[private/dovecot-lmtp] said: 550 5.1.1 <magic@flame.org> User doesn't exist: magic@flame.org (in reply to RCPT TO command)) Mar 4 05:19:51 postmark amavis[2652]: (02652-03) Blocked SPAM {DiscardedInbound,Quarantined}, [104.47.32.220]:51712 [41.113.167.214] <> -> <magic@flame.org>, quarantine: nF3hoWyr2q8z, Message-ID: <201803040520.w2453hAe025317@efectiva.com.pe>, mail_id: nF3hoWyr2q8z, Hits: 20.356, size: 20671, dkim_sd=selector1-efectiva-com-pe:efectivasa.onmicrosoft.com, 2168 ms Mar 4 05:19:51 postmark postfix/smtpd[10384]: proxy-accept: END-OF-MESSAGE: 250 2.7.0 Ok, discarded, id=02652-03 - spam; from=<> to=<magic@flame.org> proto=ESMTP helo=<NAM01-SN1-obe.outbound.protection.outlook.com> ``` What's strange here is that the message looks like it's rejected, but then is passed through amavis, which quarantines it.
Author
Owner

@tonioo commented on GitHub (Mar 7, 2018):

@skandragon Amavis is configured to quarantine SPAM by default so I don't see any bug here.
What do you want to do?

<!-- gh-comment-id:371216371 --> @tonioo commented on GitHub (Mar 7, 2018): @skandragon Amavis is configured to quarantine SPAM by default so I don't see any bug here. What do you want to do?
Author
Owner

@skandragon commented on GitHub (Mar 9, 2018):

I feel it should not quarantine spam for addresses which do not exist, it should just outright discard them. That's the problem -- the address "magic@flame.org" is not a valid recipient, and it just clutters the quarantine having it there, as it will never be accepted.

<!-- gh-comment-id:371892707 --> @skandragon commented on GitHub (Mar 9, 2018): I feel it should not quarantine spam for addresses which do not exist, it should just outright discard them. That's the problem -- the address "magic@flame.org" is not a valid recipient, and it just clutters the quarantine having it there, as it will never be accepted.
Author
Owner

@ghost commented on GitHub (Mar 9, 2018):

This isn't an amavis problem it's an issue with postfix, if the address doesn't exist it should be rejected before it gets passed to amavis.

Can you post the output of postconf -nf.

<!-- gh-comment-id:371902067 --> @ghost commented on GitHub (Mar 9, 2018): This isn't an amavis problem it's an issue with postfix, if the address doesn't exist it should be rejected before it gets passed to amavis. Can you post the output of `postconf -nf`.
Author
Owner

@skandragon commented on GitHub (Mar 9, 2018):

postconf.txt

<!-- gh-comment-id:371921728 --> @skandragon commented on GitHub (Mar 9, 2018): [postconf.txt](https://github.com/modoboa/modoboa/files/1798154/postconf.txt)
Author
Owner

@ghost commented on GitHub (Mar 9, 2018):

The only possible cause I can see is this:

virtual_alias_maps = pcre:/etc/postfix/virtual_aliases.pcre
    proxy:pgsql:/etc/postfix/sql-aliases.cf

What's in /etc/postfix/virtual_aliases.pcre?


Do you have catch all alias? (an alias with the email set to @flame.org)

<!-- gh-comment-id:371930003 --> @ghost commented on GitHub (Mar 9, 2018): The only possible cause I can see is this: ``` virtual_alias_maps = pcre:/etc/postfix/virtual_aliases.pcre proxy:pgsql:/etc/postfix/sql-aliases.cf ``` What's in `/etc/postfix/virtual_aliases.pcre`? ---- Do you have catch all alias? (an alias with the email set to `@flame.org`)
Author
Owner

@skandragon commented on GitHub (Mar 15, 2018):

There are three aliases, one which will redirect root@ for several hosts to my personal email address, and two that re-map emails in the older qmail-format user-extra@flame.org to user+extra@flame.org syntax. There's no catch-all, in that every address in that file has an explicit user@host pattern.

Note that there are exactly two - to + mappings: they are two explicit usernames, it's also not a general purpose catch-all, and nothing in that file should match the targets like magic@flame.org unless something is very broken with pcre...

<!-- gh-comment-id:373556521 --> @skandragon commented on GitHub (Mar 15, 2018): There are three aliases, one which will redirect root@ for several hosts to my personal email address, and two that re-map emails in the older qmail-format `user-extra@flame.org` to `user+extra@flame.org` syntax. There's no catch-all, in that every address in that file has an explicit user@host pattern. Note that there are exactly two - to + mappings: they are two explicit usernames, it's also not a general purpose catch-all, and nothing in that file should match the targets like `magic@flame.org` unless something is very broken with pcre...
Author
Owner

@tonioo commented on GitHub (Apr 6, 2018):

@skandragon It might be a before-queue filtering issue... (that's how the installer deploys amavis by default) See http://www.postfix.org/SMTPD_PROXY_README.html.

<!-- gh-comment-id:379231016 --> @tonioo commented on GitHub (Apr 6, 2018): @skandragon It might be a before-queue filtering issue... (that's how the installer deploys amavis by default) See http://www.postfix.org/SMTPD_PROXY_README.html.
Author
Owner

@skandragon commented on GitHub (Apr 11, 2018):

What is the recommended configuration, and which installer set this up as a before-queue filter?

<!-- gh-comment-id:380338436 --> @skandragon commented on GitHub (Apr 11, 2018): What is the recommended configuration, and which installer set this up as a before-queue filter?
Author
Owner

@tonioo commented on GitHub (Oct 1, 2018):

@skandragon Are you still encountering this issue?

When the content filter is configured to work in "before queue" mode, it will deal with messages before any address resolution is made by postfix. If you want to avoid it, change postfix's config to run amavis in "after queue" mode.

<!-- gh-comment-id:425872325 --> @tonioo commented on GitHub (Oct 1, 2018): @skandragon Are you still encountering this issue? When the content filter is configured to work in "before queue" mode, it will deal with messages before any address resolution is made by postfix. If you want to avoid it, change postfix's config to run amavis in "after queue" mode.
Author
Owner

@vtoc commented on GitHub (Jun 12, 2020):

@tonioo the better solution is to check before queue, you only need to add

virtual_mailbox_maps = pgsql:/etc/postfix/sql/sql-mailboxes.cf
password = donttell
dbname = modoboa
hosts = localhost
query = SELECT 'OK' FROM admin_mailbox LEFT JOIN admin_domain ON admin_mailbox.domain_id = admin_domain.id WHERE admin_mailbox.address='%u' AND admin_domain.name='%d' LIMIT 1;

This will check the user before accepting the mail and reject if otherwhise and only after it will pass the mail to amavis, which still can reject before queue and thus won't bounce spam

<!-- gh-comment-id:643447414 --> @vtoc commented on GitHub (Jun 12, 2020): @tonioo the better solution is to check before queue, you only need to add ``` virtual_mailbox_maps = pgsql:/etc/postfix/sql/sql-mailboxes.cf ``` ```user = postfix password = donttell dbname = modoboa hosts = localhost query = SELECT 'OK' FROM admin_mailbox LEFT JOIN admin_domain ON admin_mailbox.domain_id = admin_domain.id WHERE admin_mailbox.address='%u' AND admin_domain.name='%d' LIMIT 1; ``` This will check the user before accepting the mail and reject if otherwhise and only after it will pass the mail to amavis, which still can reject before queue and thus won't bounce spam
Author
Owner

@skandragon commented on GitHub (Jun 19, 2020):

Will this also handle user+foo@ and user-foo@ if postfix is set up to handle this elsewhere?

<!-- gh-comment-id:646527037 --> @skandragon commented on GitHub (Jun 19, 2020): Will this also handle user+foo@ and user-foo@ if postfix is set up to handle this elsewhere?
Author
Owner

@stale[bot] commented on GitHub (Oct 23, 2020):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

<!-- gh-comment-id:715534810 --> @stale[bot] commented on GitHub (Oct 23, 2020): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Author
Owner

@stale[bot] commented on GitHub (Dec 22, 2020):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

<!-- gh-comment-id:749749899 --> @stale[bot] commented on GitHub (Dec 22, 2020): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/modoboa-modoboa#1123
No description provided.