, use "virtual_alias_domains" to enumerate any virtual alias
domains, and "virtual_alias_maps". DO NOT reply on the
backwards-compatible (with Postfix 1.x 20+ years ago) default value of
"virtual_alias_domains":
virtual_alias_domains = $virtual_alias_maps
Ins
ill
> use local unix users.
If you have for example domains example1.com, example2.com and example3.com,
one of them (say example1.com) can be your "main" domain where you use unix
users as mail destinations, ie. use...@example1.com. You DON'T put any
addresses in that domain in virtua
EADME
> - ADDRESS_REWRITING_README
> - The virtual(5) manpage
> - The postconf(5) descriptions of:
> * virtual_alias_domains
> * virtual_alias_maps
>
> DO NOT use the deprecated "virtual_domains" parameter, it mixes
> classification of
s_domains
* virtual_alias_maps
DO NOT use the deprecated "virtual_domains" parameter, it mixes
classification of domains with address mappings.
> However, in my virtual aliases table on OpenSMTPd, I have the following
> line-types
It is best to not use the same terminology for two differe
Hey all,
I found a second topic where I am not sure how postfix behaves.
The old virtual_domains file just lists all domains (one per line), and can
directly be used in
virtual_alias_domains.
However, in my virtual aliases table on OpenSMTPd, I have the following
line-types
On Mon, May 08, 2023 at 12:33:31PM +1000, Sean Gallagher via Postfix-users
wrote:
> > [ Yes, one could also craft "classless" access(5) tables, ... and rely
> >only on explicit transport(5) table entries, opting out of all the
> >taxonomy that makes it easier to reason about Postfix mail
Viktor Dukhovni via Postfix-users writes:
> (...)
> [ Yes, one could also craft "classless" access(5) tables, ... and rely
> only on explicit transport(5) table entries, opting out of all the
> taxonomy that makes it easier to reason about Postfix mail routing,
> but this is not a good
, in the belief I
am not a uniquirely incapable or unintelligent reader.
1) virtual_alias_maps is not only applied to virtual_alias_domains,
but to _all_ domains that Pf receives mail for.
http://www.postfix.org/ADDRESS_CLASS_README.html is very misleading in
this respect. I really wish I had
[ Yes, one could also craft "classless" access(5) tables, ... and rely
only on explicit transport(5) table entries, opting out of all the
taxonomy that makes it easier to reason about Postfix mail routing,
but this is not a good idea, and users advanced enough to do that
aren't the
recipient table
> - that's the class-full part.
One could also turn off recipient validation entirely, and Postfix would
still have meaninful address classes, because these are the basis of
transport resolution and relay control.
Adding a recipient to virtual_alias_maps DOES NOT make Postfix
On 8/05/2023 10:19 am, Wietse Venema via Postfix-users wrote:
Sean Gallagher via Postfix-users:
ADDRESS_CLASS_README:
The most misleading place for me was the ADDRESS_CLASS_README
For "The virtual alias domain class" it says:
"Valid recipient addresses are listed with the vir
On Mon, May 08, 2023 at 09:55:28AM +1000, Sean Gallagher via Postfix-users
wrote:
> Q: how would an entry in virtual_alias_maps like
> localpart@$virtual_alias_domains localpart@$virtual_alias_domains be
> handled?
> A: It would stay in $virtual_alias_domains and be handed to
> {
Sean Gallagher via Postfix-users:
> ADDRESS_CLASS_README:
>
> The most misleading place for me was the ADDRESS_CLASS_README
>
> For "The virtual alias domain class" it says:
> "Valid recipient addresses are listed with the virtual_alias_maps
>
ADDRESS_CLASS_README:
The most misleading place for me was the ADDRESS_CLASS_README
For "The virtual alias domain class" it says:
"Valid recipient addresses are listed with the virtual_alias_maps
parameter"
which is of course true, but there is nothing special about the v
Matus UHLAR - fantomas via Postfix-users:
> I looked at docs (*README) and haven't found any.
>
> I'd still prefer to explicitly note that virtual_alias_maps are applied
> even for non-local e-mail
> ...you use "all email deliveries", I wonder if something like
> &qu
oints of confusion, in the belief I
>am not a uniquirely incapable or unintelligent reader.
>
>1) virtual_alias_maps is not only applied to virtual_alias_domains,
>but to _all_ domains that Pf receives mail for.
>http://www.postfix.org/ADDRESS_CLASS_README.html is very misleading in
&
minded individual
> >
> >I simply want to help others avoid my points of confusion, in the belief I
> >am not a uniquirely incapable or unintelligent reader.
> >
> >1) virtual_alias_maps is not only applied to virtual_alias_domains,
> >but to _all
, in the belief I
am not a uniquirely incapable or unintelligent reader.
1) virtual_alias_maps is not only applied to virtual_alias_domains,
but to _all_ domains that Pf receives mail for.
http://www.postfix.org/ADDRESS_CLASS_README.html is very misleading in
this respect. I really wish I had understood
reader.
1) virtual_alias_maps is not only applied to virtual_alias_domains, but
to _all_ domains that Pf receives mail for.
http://www.postfix.org/ADDRESS_CLASS_README.html is very misleading in
this respect. I really wish I had understood this earlier, it would have
saved a lot of time.
2) macros
On Sat, Dec 17, 2022 at 11:32:18PM +0100, Michael Ströder wrote:
> I've added DKIM signing with this config snippet:
DKIM signs the message headers and body.
> But I also have simple mail group expansion with virtual alias maps:
The virtual(5) table rewrites only the message envelope.
--
also have simple mail group expansion with virtual alias maps:
virtual_alias_maps =
proxy:ldap:/etc/postfix/ldap_list_aliases-nisMailAlias.cf,proxy:ldap:/etc/postfix/ldap_virtual.cf
So DKIM signing happens *before* list expansion which seems wrong.
Any way to fix this without running multiple
Tuesday, February 22, 2022, 11:27:30 AM, post...@ptld.com wrote:
>> There doesn't appear to be a way to say "here is user and this is his
>> email address". It seems to be assumed that user "Fred" will have an
>> email
>> address of "fred@..." and no way to override that.
> That is not how
> There doesn't appear to be a way to say "here is user and this is his
> email address". It seems to be assumed that user "Fred" will have an
> email
> address of "fred@..." and no way to override that.
That is not how dovecot works. Dovecot goes "here is this authenticated user
and they are
* Phil Biggs:
> There doesn't appear to be a way to say "here is user and this is his
> email address". It seems to be assumed that user "Fred" will have an
> email address of "fred@..." and no way to override that.
Tuesday, February 22, 2022, 8:58:32 AM, Jaroslaw Rafa wrote:
> Dnia 22.02.2022 o godz. 08:00:44 Phil Biggs pisze:
>>
>> This is the thing that I could not figure out from the Dovecot
>> documentation - mapping between Dovecot login names and mailboxes.
> As far as I understand, Dovecot
Dnia 22.02.2022 o godz. 08:00:44 Phil Biggs pisze:
>
> This is the thing that I could not figure out from the Dovecot
> documentation - mapping between Dovecot login names and mailboxes.
As far as I understand, Dovecot "userdb" specifies this:
not typical use case.
I do apologize. I thought I had mentioned using LMTP but really should have
included all of this anyway:
virtual_mailbox_domains = pjb.cc
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
virtual_transpo
Monday, February 21, 2022, 10:59:10 PM, Jaroslaw Rafa wrote:
> Dovecot comes into play only when user logs in to IMAP account. It keeps its
> own mapping between login names (which do not need to be email addresses,
> they can be just any names) and mailboxes corresponding to these users.
>
On 2022-02-20 01:49, Phil Biggs wrote:
I have virtual_mailbox_maps in use with reject_unlisted
_recipent and use virtual_alias_maps to translate a
validated address into a single matching
address for the corresponding dovecot user. For example:
/usr/local/etc/postfix/vmailbox
validu
Dnia 21.02.2022 o godz. 13:09:19 Alexey Shpakovsky pisze:
> On Mon, February 21, 2022 12:59, Jaroslaw Rafa wrote:
> >
> > The part I am wondering about is exactly "Dovecot accepts". As far as I
> > know, Dovecot does not need to "accept" anything, because it does not
> > receive mail.
>
> > At
eed for
aliases here. Unless you want mail for several different email addresses to
be delivered to the same mailbox, in that case you would need
virtual_alias_maps mapping email@address1->destination@address,
email@address2->destination@address etc., and virtual_mailbox_maps mapping
destina
d to (internal) dovecotuser@
>> via virtual_alias_maps
>> - only dovecotuser@ addresses are accepted by dovecot
>> - emails originally addressed to dovecotuser@ addresses are rejected
> Just asking: how do you deliver mail to Dovecot so that it needs to know and
> accept an
Dnia 21.02.2022 o godz. 13:10:45 Phil Biggs pisze:
>
> - emails sent to (external) validuser@ addresses are validated
> as present in virtual_mailbox_maps
> - validuser@ addresses are translated to (internal) dovecotuser@
> via virtual_alias_maps
> - only dovecotuser@ addr
Monday, February 21, 2022, 5:04:59 AM, Matus UHLAR - fantomas wrote:
> On 20.02.22 18:49, Phil Biggs wrote:
>>I have virtual_mailbox_maps in use with reject_unlisted_recipent and use
>>virtual_alias_maps to translate a validated address into a single matching
>>address
On 20.02.22 18:49, Phil Biggs wrote:
I have virtual_mailbox_maps in use with reject_unlisted_recipent and use
virtual_alias_maps to translate a validated address into a single matching
address for the corresponding dovecot user.
virtual_alias_maps map any address (even non-local one) to one
I have virtual_mailbox_maps in use with reject_unlisted_recipent and use
virtual_alias_maps to translate a validated address into a single matching
address for the corresponding dovecot user. For example:
/usr/local/etc/postfix/vmailbox
validu...@example.com whatever
/usr/local/etc
On 31.07.21 20:55, Wietse Venema wrote:
> Please also provide output from
>
> postconf -P
There is only syslog and submission stuff in postconf -P. The true
problem seems to have been that I didn't delete the verify_cache.db
after changing the virtual alias map.
- Florian.
Please also provide output from
postconf -P
I suspect that you have virtual alias mapping disabled in some
message delivery path (with receive_override_options =
no_address_mappings).
Wietse
Hi,
I am currently slightly confused by the interaction between
recipient_delimiter and virtual_alias_maps. I have a test setup with
recipient_delimiter = +
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_transport = lmtp:unix:private/dovecot-lmtp
a virtual domain "domain" an
On 04/06/2021 12:10, Viktor Dukhovni wrote:
> On Fri, Jun 04, 2021 at 10:53:25AM +0300, Kapetanakis Giannis wrote:
>
>> I want to separate the ldap configuration to be different per domain.
>> I was thinking something like this, but this recursion does not work:
>>
>> The reason is that the ldap
On Fri, Jun 04, 2021 at 10:53:25AM +0300, Kapetanakis Giannis wrote:
> I want to separate the ldap configuration to be different per domain.
> I was thinking something like this, but this recursion does not work:
>
> The reason is that the ldap search_base might be different per domain (no
>
Hi,
My virtual_alias_maps looks like this:
virtual_alias_maps = hash:/etc/postfix/virtual,
ldap:/etc/postfix/ldap-aliases.cf
I want to separate the ldap configuration to be different per domain.
I was thinking something like this, but this recursion does not work:
virtual_alias_maps = hash
On 18.01.21 12:45, Daniel Caillibaud wrote:
>After switching to rspamd (was amavis+spamassassin), virtual_alias_maps seems
to be ignored
>(mail to aliases address are bounced with "user unknown"), and I don't find
why…
Le 18/01/21 à 13:13, Matus UHLAR - fantomas a écr
Le 18/01/21 à 13:13, Matus UHLAR - fantomas a écrit :
> On 18.01.21 12:45, Daniel Caillibaud wrote:
> >After switching to rspamd (was amavis+spamassassin), virtual_alias_maps
> >seems to be ignored
> >(mail to aliases address are bounced with "user unknown"), and I
On 18.01.21 12:45, Daniel Caillibaud wrote:
After switching to rspamd (was amavis+spamassassin), virtual_alias_maps seems
to be ignored
(mail to aliases address are bounced with "user unknown"), and I don't find why…
you turned on:
receive_override_options = no_address_mappings
Hi,
After switching to rspamd (was amavis+spamassassin), virtual_alias_maps seems
to be ignored
(mail to aliases address are bounced with "user unknown"), and I don't find why…
1) Before (all is fine with virtual_alias_maps)
content_filter=amavis:[127.0.0.1]:10024
milter_pr
> Am 09.01.2021 um 13:25 schrieb Leonardo Rodrigues :
>
> Em 09/01/2021 06:25, Frank Röhm escreveu:
>> I would put then:
>>
>> /^.*@mydomain.tld$/ fr...@mydomain.tld
>>
>> Would that be correct?
>> I don’t want to just test it, it is a productive mailserver.
>>
>>
>
> Never
Em 09/01/2021 06:25, Frank Röhm escreveu:
I would put then:
/^.*@mydomain.tld$/ fr...@mydomain.tld
Would that be correct?
I don’t want to just test it, it is a productive mailserver.
Never actually tried it, bur first thing that cames to my mind is
"why not let MySQL solve the
Hallo
I wonder if I could add a regexp rule to my virtual_alias_maps so I could
realize wildcard addresses, like:
somew...@mydomain.tld > fr...@mydomain.tld
At the moment I have:
virtual_alias_maps =
mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email
Fred Morris:
> With postfix 3.3.1 it appears that mappings in virtual_alias_maps are
> honored without the domains being listed in virtual_alias_domains. Just
> want to confirm that this is correct and intended behavior going forward.
The first sendence in the manpage says:
The
With postfix 3.3.1 it appears that mappings in virtual_alias_maps are
honored without the domains being listed in virtual_alias_domains. Just
want to confirm that this is correct and intended behavior going forward.
Thanks in advance...
--
Fred Morris
On Sat, Oct 10, 2020 at 05:15:37PM +0200, Marek Kozlowski wrote:
> Is it possible to accept mail if the recipients address is found in
> virtual_alias_maps and reject in all other cases? Let's imagine I have
> two entries for virtual_alias_maps:
Following http://www.po
Wietse Venema:
> Marek Kozlowski:
> > :-)
> >
> > Must be simple... but I missed it.
>
> The answer is in http://www.postfix.org/ADDRESS_CLASS_README.html.
>
> If you don't want to receive and deliver email for the local class,
> set local_recipient_maps to empty, or set the local_transport to
Marek Kozlowski:
> :-)
>
> Must be simple... but I missed it.
The answer is in http://www.postfix.org/ADDRESS_CLASS_README.html.
If you don't want to receive and deliver email for the local class,
set local_recipient_maps to empty, or set the local_transport to
"error:email to this domain is
:-)
Must be simple... but I missed it.
I asked for it in the context on LDAP but I think I may simplify my
question:
Is it possible to accept mail if the recipients address is found in
virtual_alias_maps and reject in all other cases? Let's imagine I have
two entries for virtual_alias_maps
David Reagan:
> Thanks. Switching the query to the default '%s' and making sure I didn't
> have 'result_format' set fixed it. The postmap query works.
>
> Is the fact that %d won't work in this context documented anywhere? I
> didn't see anything in http://www.postfix.org/pgsql_table.5.html or
Thanks. Switching the query to the default '%s' and making sure I didn't
have 'result_format' set fixed it. The postmap query works.
Is the fact that %d won't work in this context documented anywhere? I
didn't see anything in http://www.postfix.org/pgsql_table.5.html or any
of the other docs
On Sat, Aug 08, 2020 at 06:42:16PM -0700, David Reagan wrote:
> By key you mean use 'raygun.zat' instead of 'k...@raygun.zat'?
The former is the lookup key that Postfix asks the lookup table to find.
> Also, if you look at the query, I use '%d'. So, unless I'm
> misunderstanding the docs,
Thanks for the response.
By key you mean use 'raygun.zat' instead of 'k...@raygun.zat'?
I did try that. The output that gave was the same, just no 'postmap:
dict_pgsql_lookup: retrieved 1 rows' line.
Also, if you look at the query, I use '%d'. So, unless I'm
misunderstanding the docs,
On 8/8/2020 1:52 PM, David Reagan wrote:
Hey all,
I'm working on configuring a mailserver that uses a PostgreSQL
database for virtual information. The database is managed by Vimbadmin.
I think I've found at least part of the problem. The
virtual_mailbox_domains setting likely isn't getting
plicate matters, the virtual_alias_maps command works just
fine.
root@32cdc5546306:/# postmap -vq 'k...@raygun.zat'
pgsql:/run/secrets/postfix_db_virt_alias_maps 2>&1
postmap: name_mask: all
postmap: name_mask: host
postmap: inet_addr_local: configured 3 IPv4 addresses
postmap: i
On Wed, Jul 8, 2020 at 4:18 PM Viktor Dukhovni
wrote:
>
> On Wed, Jul 08, 2020 at 04:12:24PM -0700, Stats Student wrote:
>
> > Let me know if what I am asking isn't clear and I'll be happy to
> > provide further details. I did post all of my configuration last week
> > but can include it in the
On Wed, Jul 08, 2020 at 04:12:24PM -0700, Stats Student wrote:
> Let me know if what I am asking isn't clear and I'll be happy to
> provide further details. I did post all of my configuration last week
> but can include it in the email, if that's the preferred method.
This list is no substitute
> >
> > I don't use transport_maps currently so it's unclear to me how this
> > would work with the existing setup which I assume already uses the
> > virtual delivery agent with virtual_transport. Can you please show an
> > example of the transport_maps with two routes?
>
> In that case you
Stats Student:
> On Wed, Jul 8, 2020 at 1:10 PM Wietse Venema wrote:
> >
> > Stats Student:
> > > > Again, an email address IS NOT an account.
> > > >
> > >
> > > Ok, understood.
> > >
> > > > If it helps to rephrase the example:
> > > >
> > > > Prerequisites:
> > > > foo@example delivers to
On Wed, Jul 8, 2020 at 1:10 PM Wietse Venema wrote:
>
> Stats Student:
> > > Again, an email address IS NOT an account.
> > >
> >
> > Ok, understood.
> >
> > > If it helps to rephrase the example:
> > >
> > > Prerequisites:
> > > foo@example delivers to script
> > > foo.maildir@example
Stats Student:
> > Again, an email address IS NOT an account.
> >
>
> Ok, understood.
>
> > If it helps to rephrase the example:
> >
> > Prerequisites:
> > foo@example delivers to script
> > foo.maildir@example delivers to maildir
>
> I don't know how to satisfy the last prerequisite.
ome_mailbox = Maildir/
>
> Use virtual_alias_maps with:
> foo@example foo@example, foo.maildir@example
>
If I understand correctly, I need to effectively "make up" two emails
for each account and somehow configure separate deliveries for each
email.
I would think the delivery
> > > > That message needs to have (surprise!) two destinations.
> > > >
> > > > 1) a destination that delivers to the script
> > > > 2) a destination that delivers to the maildir file
> > > >
> > > > You can add that second
t;
> > > 1) a destination that delivers to the script
> > > 2) a destination that delivers to the maildir file
> > >
> > > You can add that second destination with virtual_alias_maps,
> > > sender_bcc_maps, recipient_bcc_maps, .forward files, and so
ssage to two destinations
> >
> > 1) a script
> > 2) a maildir file
> >
> > That message needs to have (surprise!) two destinations.
> >
> > 1) a destination that delivers to the script
> > 2) a destination that delivers to the maildir
) a script
> 2) a maildir file
>
> That message needs to have (surprise!) two destinations.
>
> 1) a destination that delivers to the script
> 2) a destination that delivers to the maildir file
>
> You can add that second destination with virtual_alias_maps,
> sender_bcc_maps, recipien
nation that delivers to the script
2) a destination that delivers to the maildir file
You can add that second destination with virtual_alias_maps,
sender_bcc_maps, recipient_bcc_maps, .forward files, and so on.
Wietse
020 at 8:31 AM Wietse Venema wrote:
> >> Add a recipient with virtual_alias_maps, sender_bcc_maps,
> >> recipient_bcc_maps, etc., and use the existing local(8) or virtual(8)
> >> delivery agent to deliver to a maildir.
>
> On 01.07.20 13:34, Stats Student wrote:
>
Stats Student:
> 1) in addition to sending the messages to a script, is there a way to
> store the messages in a real mailstore ( Maildir ) ?
On Wed, Jul 1, 2020 at 8:31 AM Wietse Venema wrote:
Add a recipient with virtual_alias_maps, sender_bcc_maps,
recipient_bcc_maps, etc., a
tudent:
> > Hi, as a follow up to this question -
> >
> > 1) in addition to sending the messages to a script, is there a way to
> > store the messages in a real mailstore ( Maildir ) ?
>
> Add a recipient with virtual_alias_maps, sender_bcc_maps,
> recipient_bcc_m
Stats Student:
> Hi, as a follow up to this question -
>
> 1) in addition to sending the messages to a script, is there a way to
> store the messages in a real mailstore ( Maildir ) ?
Add a recipient with virtual_alias_maps, sender_bcc_maps,
recipient_bcc_maps, etc., and use the exis
xisting
> > users, and 'not found' otherwise. See "man pgsql_table", especially
> > the section "LIST MEMBERSHIP".
> >
> > > 2) for a handful of accounts (postmaster, help, root), the messages
> > > should be forwarded to another addres
On Wed, 10 Jun 2020, Matus UHLAR - fantomas wrote:
> On 10.06.20 12:48, Jozsef Kadlecsik wrote:
> > handled@by.exchange handled@by.dovecot,handled@by.exchange
> >
> > The problem is that the address handled@by.dovecot receives every email
> > sent to handled@by.exchange twice:
On 10.06.20 12:48, Jozsef Kadlecsik wrote:
handled@by.exchange handled@by.dovecot,handled@by.exchange
The problem is that the address handled@by.dovecot receives every email
sent to handled@by.exchange twice: handled@by.exchange is expanded before
amavisd is called, and also after receiving
On 10.06.20 12:48, Jozsef Kadlecsik wrote:
handled@by.exchange handled@by.dovecot,handled@by.exchange
The problem is that the address handled@by.dovecot receives every email
sent to handled@by.exchange twice: handled@by.exchange is expanded before
amavisd is called, and also after receiving
Hello,
We have a virtual_alias_maps entry like this
handled@by.exchange handled@by.dovecot,handled@by.exchange
The problem is that the address handled@by.dovecot receives every email
sent to handled@by.exchange twice: handled@by.exchange is expanded before
amavisd is called, and also
handful of accounts (postmaster, help, root), the messages
> > should be forwarded to another address (different domain). Would be
> > great for this forwarding to take place without going through the
> > processing script in (1).
>
> Use virtual_alias_maps:
>
> /etc/postf
ful of accounts (postmaster, help, root), the messages
> should be forwarded to another address (different domain).
This is easily handled via virtual_alias_maps, rewriting the recipients in
question.
> Would be great for this forwarding to take place without going through the
> processing scrip
ded to another address (different domain). Would be
> great for this forwarding to take place without going through the
> processing script in (1).
Use virtual_alias_maps:
/etc/postfix/main.cf:
virtual_alias_maps = hash:/etc/postfix/virtual
/etc/postfix/virtual:
postmaster user1@ex
ress (different domain). Would be
> great for this forwarding to take place without going through the
> processing script in (1).
Use virtual_alias_maps:
/etc/postfix/main.cf:
virtual_alias_maps = hash:/etc/postfix/virtual
/etc/postfix/virtual:
postmaster user1@example
rootuser2
#advanced_filter)
and virtual_alias_maps.
But for some reason (receive_override_options = no_address_mappings)
causes the server to ignore users in virtual_alias_maps and bounce.
Hence the question.
I used to use qpsmtpd on port 10025 with a custom plugin (in Perl)
which did the processing - but maybe
Mattia Rizzolo:
> Is it possible to have anything like that? Also assuming in the future
> this host will have to handle a separate domain, I'd prefer to have
> different files for each set of aliases, and keep it tidy.
Postfix supports multiple aliases files; that is usually how mailman
is
/aliases
myorigin = /etc/mailname
mydestination = mail1.example.org, localhost
relay_domains = lists.example.org
virtual_alias_maps = hash:/etc/postfix/virtual_domains
mailman_destination_recipient_limit = 1
transport_maps = hash:/etc/postfix/transport
-
- master.cf
mailman unix
Thanks Yassine thats very helpful. Im going to modify the config to do
it all with virtual_alias_maps
On 27/03/2019 10:56, Yassine Chaouche wrote:
On 3/27/19 11:19 AM, Andrew Wood wrote:
What is the difference between setting up an alias in
virtual_alias_maps and virtual_mailbox_maps?
I
On 3/27/19 11:19 AM, Andrew Wood wrote:
What is the difference between setting up an alias in
virtual_alias_maps and virtual_mailbox_maps?
I can make alias@domain point to a mailbox by pairing it with the path
to the maildir in virtual_mailbox_maps but it seems if I do that the
alias can
What is the difference between setting up an alias in virtual_alias_maps
and virtual_mailbox_maps?
I can make alias@domain point to a mailbox by pairing it with the path
to the maildir in virtual_mailbox_maps but it seems if I do that the
alias can only point to one mailbox not multiple
main rhyno.tech in BOTH virtual_alias_domains and
> virtual_mailbox_domains//
> //...but then how do i tell postfix that i need it to check for aliased
> addresses before attempting virtual delivery?)/
As documented, virtual_alias_maps is ALWAYS searched.
Wietse
it to check for aliased
addresses before attempting virtual delivery?)/
# Virtual aliases
virtual_alias_maps = proxy:hash:/etc/postfix/virtual_aliases
# Valid virtual recipients
#virtual_mailbox_maps = proxy:ldap:/etc/postfix/ldap/virtual_boxes.cf
/(yes, there is no virtual_mailbox_maps as i didn't
Hi,
Am 20.05.2018 um 16:40 schrieb Wietse Venema:
[...]
> Indeed. With Postfix 2.4 and later, both the virtual(5) and
> canonical(5) manpages document that wildcard address mappings will
> break adress validation.
>
Yes i read that but as said was surprised that this included lookups to
the very
equinox:
> Re-reading the documentation over and over again i yesterday realized
> that a simple non-regexp table containing
>
>
> @example.com@example.org
> ...
>
>
> does suffice to do the same thing. However the problem i'm having stays
> the same.
Indeed. With Postfix 2.4 and later,
server. The MX hosts use virtual_domains
and virtual_alias_maps to check whether a specific recipient exists and
then forward the mail to the internal host or in some cases to external
mail servers.
For years now the virtual_alias_map for example.org and example.com
looked like
ddress with.
Use a PCRE table, capture the original address with (), and
place it in the expansion as $1:
/etc/postfix/virtual.pcre:
/(.+@example\.com$) $1, addr, addr
/etc/postfix/main.cf:
virtual_alias_maps = pcre:/etc/postfix/virtual.pcre, othermaps...
In the left-hand pattern, the '\' and '$' are required to avoid
false matches.
Wietse
Hello,
If I have a virtual alias map like this:
@domain.tldsomeaddr...@otherdomain.tld superaddr...@somedomain.tld
Then all e-mails to domain.tld will be forwarded to the two given
addresses, right?
Fine. But then, I want those e-mails to be delivered to the original
recipient too. For
thx noel!
you are absolutely right - the proper way is to create a 2 restriction classes.
thx again!
On 12/09/2016 05:22 PM, Noel Jones wrote:
> On 12/9/2016 9:11 AM, Harald Glanzer wrote:
>> hi all!
>>
>> i am using virtual_alias_maps for a simple 'mainlinglist' configur
1 - 100 of 396 matches
Mail list logo
