catchall email catching ALL email (also email for other accounts)

Hi, I'm currently migrating a setup of several virtual servers from plesk to virtualmin.

Most are web-only, but there is one of which is actually used for email. On that server, there should be several "real" user accounts. (think "me@server.tld", "my_wife@server.tld" etc.), plus there should be a pseudo-catch-all that catches everything that doesn't belong to any of the "real" accounts.

I know it's discouraged. The background is that I have used this successfully for spam protection under plesk: Everytime I create an account somewhere (say, at "business.com") I create a new email address called business.com@server.tld and depended on the plesk catch-all for delivery. More than once, this helped me identify and de-activate hacked accounts somewhere (if an email claims, for example, to come from paypal but doesn't use the paypal mail account, it's obviously a fake). And because my server is basically unknown, I have no real problems with spammers using random account names. Happens two, three times a year.

The problem is: I have lost track. So I need, at least for a limited time of a year or so, the catch-all-behaviour from plesk: try to deliver to a real mailbox, if no real mailbox is there, deliver to "me@server.tld".

If I try to configure that (via an alias "@server.tld" under edit users -> email settings or via the "all users" alias under edit email aliases), ALL mail goes to me@server.tld, including my_wife@server.tld.

You won't be surprised to hear that my wife doesn't like that.

The only thing I can think of is that I have disabled the administration user's email functionality. As a test, I had it enabled but it doesn't make a difference.

Status: 
Active

Comments

It seems to be a known "feature" of postfix to prioritize aliases over "real" mailboxes. Thomas Leister recommends here to create an alias that redirects to the "real" mailbox (because then the more specific alias is supposed to win). However, adding such an alias seems to be "swallowed" by virtualmin. I'll keep trying.

OK, here's what I did: as the UI doesn't allow this, I've manually edited the alias file and added

my_wife@server.tld::my_wife.server

(where my_wife.server is the corresponding accountname)

The remaining problem is: virtualmin rewrites the config files at a rhythm I can't figure.

Correction. Somhow, I've knocked out the catch-all alias in the process :-(

So if you have a catchall for a domain in /etc/postfix/virtual and regular aliases that point to users, the regular aliases should match first.

Can you post all /etc/postfix/virtual lines for this domain so I can see what's going on?

Hi Jamie, thanks for looking into this.

For the purpose of this test, I have gone back from the current live setup (as many aliases manually / individually restored as possible) to the set-up that creates the problem:

Here is a snippet from the /etc/postfix/virtual that exposes the problem:

(actual configuration removed after a few days because it contains personal data, screenshot available on request)

Admittedly, I do not see where the line ... or ... come from.

These are all the lines for the present hoste, but note that some of these accounts are also forwarding targets in other virtual hosts. All in all, there are ~100 more lines referring to other hosts. I hope I didn't miss an important one.

With this /etc/postfix/virtual I have sent a test-email from the outside to (existing alias 1 / configured catch-all), (existing alias 2) and (non-existing alias).

The expected behavior is that (existing alias 1) receives two copies of that mail (one because it is an explicit recipient, and one because (non-existing alias) runs into the catch-all mechanism and is delivered to there for that reason), and one copy goes to (existing alias 2).

The actual behavior is that three copies are delivered to (existing alias 1) and none to (existing alias 2).

P.S.: If you don't mind, I'll rewrite all the actual email addresses in at most 24h.

That's surprising, as I would also expect it to work the way you expected!

Can you try running postmap /etc/postfix/virtual to ensure that the real map file DB is up to date?

Same test. Two emails, one "without" and one "with" running postmap. Same outcome: all three emails get delivered to josef@dietl.org in both cases.

What is cuious, though, is that it is pretty hard to re-create the same /etc/postfix/virtual twice in a row through the UI. (after all, I'm using virtualmin so that I do NOT have to worry about configuration files)

Here is the file snippet I created:

(actual configuration removed after a few days because it contains personal data, screenshot available on request)

and here is why I think this is weird:

  • I don't see where the line alias1@domain.tld alias2@domain.tld is coming from
  • That line doesn't make sense. There should be two aliases, alias1@domain.tld and alias2@domain.tld, both mapping to user@domain.tld.

So I figured it's time to closely examine the other 50 or so lines in /etc/postfix/virtual that deal with other domains. Note that there are some redirects into the domain.tld domain such as postmaster@otherdomain.tld     otherdomain@domain.tld, but they appear harmless to me. But there is one line:

domain.tld domain.tld

I don't know where it came from, and I don't understand what it does, and at least until I understand where it came from, I'm reluctant to remove it. (Because it may come back as a surprise when I change/save some "unrelated" configuration.

Is this the "missing link", or am I setting everybody on a wrong trail here?

The line dietl.org dietl.org is expected - it just tells Postfix that there are virtual file entries for that domain.

Regarding the wpml entry, can you attach a screenshot of the Virtualmin UI for that user or alias?

Regarding the wpml entry: It may just have been a glitch in the many copy&paste processes (after all, I'm running the manual list of aliases now but would like to have my old "catch all where no specific rules exist" behaviour back, so for every experiment I'm c&p'ing a working configuration away, recreate what I'd like to have, run one experiment and change everything back...). Sorry for the confusion. I have manually changed the entry now.

Also, a new version of virtualmin arrived the other day. I tried it out, but the problem is still there. Is it possible that the problem is somewhere in Postfix 2.11.3 and has nothing to to with Virtualmin?

Yes, this could be a Postfix bug. You might want to ask Postfix experts how virtusers are expected to work in this situation, because what's happening is not what I expected.