Solved Going crazy with Postfix virtual recipient

Hi everyone,

I'm going mad with adding new virtual recipient to Postfix's virtual recipient address.
I have a working virtual config file located in /usr/local/etc/postfix :

Code:
leo@mydomain.tld              leo
contact@mydomain.tld          max
cvsup@mydomain.tld            leo

The first two lines are already working well.
But for a strange reason, adding the last one (cvsup) and performing a :
postmap /usr/local/etc/postfix/virtual
... and then restarting postfix's service is not working.

I get an error from Postfix :
Code:
Apr 16 09:52:48 vendome postfix/smtpd[5952]: NOQUEUE: reject: RCPT from smtp3-g21.domain.fr[212.27.XX.X]: 450 4.1.1 <cvsup@mydomain.tld>: Recipient address rejected: unverified address: host mail.mydomain.tld[/var/imap/socket/lmtp] said: 550-Mailbox unknown.  Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown (in reply to RCPT TO command); from=<external@email.address> to=<cvsup@mydomain.tld> proto=ESMTP helo=<smtp3-g21.domain.fr>

Is there something I'm missing there ?

Thanks,

--
Léo.
 
Additionnally, if I add another new line after the cvsup one, for example :
test@mydomain.tld leo
... doing postmap and then restarting the service, the mails to test@mydomain.tld are delivered correctly.

Is the cvsup email address protected or something ?

--
Léo.
 
Where is your virtual_alias_maps pointing in main.cf ?

ps
virtual_mailbox_maps = ?????
virtual_alias_maps = ????
 
Hi VladiBG :)

Thanks for taking some time for me.


Code:
root@vendome:/usr/local/etc/postfix # postconf | grep virtual_
[...]
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
[...]
virtual_mailbox_maps =

--
Léo.
 
So you already have the answer for your question. Read about mailbox_maps and alias_maps from here: http://www.postfix.org/VIRTUAL_README.html

p.s.
when you learn how all works delete the entire configuration and set up it again several times until you start feel comfortable with it. After that go ahead and proceed with postgresql + postfixadmin it will make your life easy.
 
That's absolutely weird... I did *nothing* more on my box since the postconf command.
I was reading your answer when I saw some new emails coming in my inbox : they were my previous tests finally delivered.

Code:
Apr 16 10:32:11 vendome postfix/lmtp[80689]: B2E1821D4746: to=<leo@mydomain.tld>, orig_to=<cvsup@domain.tld>, relay=127.0.0.1[127.0.0.1]:10024, delay=1.9, delays=0.11/0/0/1.8, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as A001D21D474C)

I didn't restarted the service, I didn't added anything to virtual_mailbox_maps (which is still empty by the way).

Maybe there's a delay after adding a new entry in the config file for virtual recipient, but it's written nowhere that we have to wait until the change propagates...
The problem is solved, but if anyone has an idea why, it would be great :)

--
Léo.
 
Maybe there's a delay after adding a new entry in the config file for virtual recipient, but it's written nowhere that we have to wait until the change propagates...
The problem is solved, but if anyone has an idea why, it would be great :)

This delay still exists.. nevermind, I'll mark this thread as solved.

--
Léo.
 
If you change a regexp:, pcre:, cidr: or texthash: file then Postfix may not pick up the file changes immediately. This is because a Postfix process reads the entire file into memory once and never examines the file again.
Postfix uses file locking to avoid access conflicts while updating Berkeley DB or other local database files. This used to be safe, but as Berkeley DB has evolved to use more aggressive caching, file locking may no longer be sufficient.
...
With Berkeley DB and other "one file" databases, it is possible to add some extra robustness by using "mv" to REPLACE an existing database file instead of overwriting it:
#postmap access.in && mv access.in.db access.db

Edit: Hm, I mangled the quotes somehow. Here are the links back into the Postfix documentation:
 
Hello Jose,

That's a great piece of information, thank you so much for taking the time to share it here.
I didn't know about that and that's a relief to finally understand why I encountered this behavior.
I'll also test your hint about adding some robustness to the command next time I'll have to modify the file !

Greetings from Paris, France :)

--
Léo.
 
Back
Top