mirror of
https://github.com/modoboa/modoboa.git
synced 2026-04-25 00:46:03 +03:00
[GH-ISSUE #1416] Reject unknown recipient addresses #1123
Labels
No labels
bug
bug
dependencies
design
documentation
duplicate
enhancement
enhancement
enhancement
feedback-needed
help-needed
help-needed
installer
invalid
looking-for-sponsors
modoboa-contacts
new-ui
new-ui
pr
pull-request
pyconfr
python
question
security
stale
webmail
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/modoboa-modoboa#1123
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @skandragon on GitHub (Mar 3, 2018).
Original GitHub issue: https://github.com/modoboa/modoboa/issues/1416
Impacted versions
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.
@ghost commented on GitHub (Mar 3, 2018):
It's part of the Postfix configuration.
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 ofmain.cf.@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.
@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.orgfrom 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:
@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.
What's strange here is that the message looks like it's rejected, but then is passed through amavis, which quarantines it.
@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?
@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.
@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.@skandragon commented on GitHub (Mar 9, 2018):
postconf.txt
@ghost commented on GitHub (Mar 9, 2018):
The only possible cause I can see is this:
What's in
/etc/postfix/virtual_aliases.pcre?Do you have catch all alias? (an alias with the email set to
@flame.org)@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.orgtouser+extra@flame.orgsyntax. 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.orgunless something is very broken with pcre...@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.
@skandragon commented on GitHub (Apr 11, 2018):
What is the recommended configuration, and which installer set this up as a before-queue filter?
@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.
@vtoc commented on GitHub (Jun 12, 2020):
@tonioo the better solution is to check before queue, you only need to add
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
@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?
@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.
@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.