he domain from
> virtual_alias_domains and adding it to virtual_mailbox_domains.
When I said option 1 is simpler, I meant what I said. There's nothing
more to it than described. Transforming a virtual alias domain to a
virtual mailbox domain, while (almost) all the recipients are rewritten
to other domain
Hello Viktor,
Thanks for the quick reply. I tried the second variant because it seems less
invasive for the existing
configuration than variant 1. I don't see all the consequences of deleting the
domain from
virtual_alias_domains and adding it to virtual_mailbox_domains.
Unfortunately va
On Thu, Mar 13, 2025 at 02:55:00PM +0100, rog7993--- via Postfix-users wrote:
> In simple terms, the configuration looks like this:
>
> /etc/postfix/main.cf:
> virtual_alias_domains = example.com
> virtual_alias_maps = hash:/etc/postfix/virtual
> transport_maps =
I can't manage to implement a new request for mail routing.
Our mail domain is listed in "virtual_alias_domains". All mail addresses and
the respective target mail
addresses are listed in the file defined in "virtual_alias_maps". An address
rewriting is therefore
On Mon, May 06, 2024 at 11:37:54AM +0200, Дилян Палаузов via Postfix-users
wrote:
> Hello,
>
> postconf(5) contains:
>
> virtual_alias_domains (default: $virtual_alias_maps)
> virtual_alias_maps (default: $virtual_maps)
> virtual_maps (default: empty)
>
> Thus
On Mon, May 06, 2024 at 11:37:54AM +0200, Дилян Палаузов via Postfix-users
wrote:
> My reading is that a domain in virtual_alias_domains can be mentioned
> neither in virtual_mailbox_domains nor as mydestination domain.
Correct, note however, that *all* recipients are subject to vir
Hello,
postconf(5) contains:
virtual_alias_domains (default: $virtual_alias_maps)
virtual_alias_maps (default: $virtual_maps)
virtual_maps (default: empty)
Thus virtual_alias_domains is by default emtpy.
VIRTUAL_README says:
• NEVER list a virtual alias domain name as a mydestination domain
On Sun, Apr 02, 2023 at 09:09:11AM +0800, fh--- via Postfix-users wrote:
> If a domain is in virtual_alias_domains only, not in the
> virtual_mailbox_domains.
This means that the underlying mailboxes (after rewriting) must be in
some other domain, i.e. Postfix will ultimately *deliver* m
/etc/postfix/virtual to map those users to the domain I
was hosting, and specified the names also in main.cf with a
virtual_alias_domains tag in that file for the domain I was hosting.
Dovecot is a part of this and that worked to allow these users to both
send and receive.
After I stupidly
Hello,
if a domain is in virtual_alias_domains only, not in the
virtual_mailbox_domains.
But there is a user on this domain putting in dovecot-users.
Can this user get authorized by dovecot SASL and have a mailbox access?
(just like the regular domain user.)
Thanks
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 Mon, Sep 21, 2020 at 11:15:01AM -0400, Wietse Venema wrote:
> > > I don't know what you're finding surprising here. There's no magic, the
> > > restrictions are evaluated *exactly* as written. There's no mention
> > > of virtual here, so for remote senders, only recipients listed in
> > >
> >
Alex:
> Hi,
>
> On Sun, Sep 20, 2020 at 10:06 PM Viktor Dukhovni
> wrote:
> >
> > On Sun, Sep 20, 2020 at 08:53:36AM -0400, Alex wrote:
> >
> > > > > smtpd_recipient_restrictions =
> > > > > permit_mynetworks,
> > > > > permit_sasl_authenticated,
> > > > > check_recipient_access pcre:/etc/p
Hi,
On Sun, Sep 20, 2020 at 10:06 PM Viktor Dukhovni
wrote:
>
> On Sun, Sep 20, 2020 at 08:53:36AM -0400, Alex wrote:
>
> > > > smtpd_recipient_restrictions =
> > > > permit_mynetworks,
> > > > permit_sasl_authenticated,
> > > > check_recipient_access pcre:/etc/postfix/local_recip_map,
> >
On Sun, Sep 20, 2020 at 08:53:36AM -0400, Alex wrote:
> > > smtpd_recipient_restrictions =
> > > permit_mynetworks,
> > > permit_sasl_authenticated,
> > > check_recipient_access pcre:/etc/postfix/local_recip_map,
> > > reject
>
> But this doesn't account for the catch-all for the vexample
recipient_restrictions with check_recipient_access. Now I'd like
> > to add a catch-all for another domain (vexample.com) using
> > virtual_alias_domains and having a problem.
> >
> > Mail is being rejected with Recipient address rejected:
> >
> > Sep 19 20:40:26
or another domain (vexample.com) using
> virtual_alias_domains and having a problem.
>
> Mail is being rejected with Recipient address rejected:
>
> Sep 19 20:40:26 propemail postfix/smtpd[503632]: NOQUEUE: reject: RCPT
> from ns3.example.com[107.155.111.2]: 554 5.7.1 :
> Recipient a
Hi,
I have a postfix-3.5.6 system on fedora32 that accepts mail for a
domain (example.com) just using $mydestination and
smtpd_recipient_restrictions with check_recipient_access. Now I'd like
to add a catch-all for another domain (vexample.com) using
virtual_alias_domains and having a pr
On 05/05/16 12:50 PM, Viktor Dukhovni wrote:
On Thu, May 05, 2016 at 12:04:09PM -0700, Jack Bates wrote:
Is there an address rewriting step that affects only virtual_alias_domains?
No.
The following achieved my desired behavior:
virtual_alias_domains = nottheoilrig.com
On Thu, May 05, 2016 at 12:04:09PM -0700, Jack Bates wrote:
> Is there an address rewriting step that affects only virtual_alias_domains?
No.
> The following achieved my desired behavior:
>
> virtual_alias_domains = nottheoilrig.com
> virtual_alias_maps = inline:{ @n
Jack Bates:
> Is there an address rewriting step that affects only virtual_alias_domains?
No, there is no address rewriting for virtual_alias_domains only
(or for relay_domains, or for virtual_mailbox_domains).
> I tried the following:
>
>virtual_alias_domains = nott
Is there an address rewriting step that affects only virtual_alias_domains?
I tried the following:
virtual_alias_domains = nottheoilrig.com
virtual_alias_maps = static:nottheoilrig
expecting to deliver all virtual_alias_domains mail to one user,
and I was surprised when ALL mail was
Le 17/09/2012 05:14, Neil Aggarwal a écrit :
> Noel:
>
>> # main.cf
>> mydestination = localhost localhost.example.com
>> virtual_alias_domains = virtual.example.com
>>
>> # virtual_alias
>> # NOTE: best to use fully-qualified domain n
Noel:
> # main.cf
> mydestination = localhost localhost.example.com
> virtual_alias_domains = virtual.example.com
>
> # virtual_alias
> # NOTE: best to use fully-qualified domain names here
> us...@virtual.example.com us...@localhost.example.com
OK, this is what I was mi
stem accounts so it looks like
> virtual_alias is a better fit for my needs.
>
Yes, that should work nicely.
Note that for virtual_alias_domains, the domain *must* be rewritten
to a different domain. Typically, this is done with something like:
# main.cf
mydestination = localhost localho
d ONLY in virtual_alias_domains
- Valid recipient addresses are specified in virtual_alias_maps
- ***IMPORTANT*** All valid recipient addresses must be aliased to
a domain NOT in virtual_alias_domains ***IMPORTANT***
Wietse
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/mail.cachebeauty.com.all.crt
smtpd_tls_key_file = /etc/ssl/mail.cachebeauty.com.key
smtpd_tls_security_level = may
unknown_local_recipient_reject_code
Le 16/09/2012 18:42, Neil Aggarwal a écrit :
> Hello:
>
> I am trying to set up virtual domain hosting following the guide on
> this page:
> http://www.postfix.org/VIRTUAL_README.html
>
> According to that page, I list the domain in virtual_alias_domains
> and NOT in my
Hello:
I am trying to set up virtual domain hosting following the guide on
this page:
http://www.postfix.org/VIRTUAL_README.html
According to that page, I list the domain in virtual_alias_domains
and NOT in mydestination.
I then listed all my user accounts in /etc/postfix/virtual and
compiled
b...@bitrate.net:
> > b) Describe the virtual alias lookup behavior in the text that
> > defines virtual alias lookups, i.e. virtual(5). If anyone uses
> > virtual aliasing then they are more likely to look there.
>
> i'm not certain the placement is ideal, but a note at the end of the VIRTUAL
>
On Apr 14, 2012, at 15.55, Wietse Venema wrote:
> The alternatives that I see are
>
> a) Spam every address class description with text that virtual alias
> mappings are class-agnostic. Then we would also have to mention
> canonical_maps,and other class-agnostic mechanisms.
on one hand, this mi
b...@bitrate.net:
> - i'm drawn to ADDRESS_CLASS_README because of the context of the
> proposed note, but is there another place in the documentation
> where it might be better served that i'm not considering?
Text about table lookups for a particular address class belongs in
the text that descri
+ * Unlike other classes' maps, virtual_alias_maps is not used solely for
+domains listed in virtual_alias_domains. See the section on VIRTUAL ALIAS
DOMAINS
+in virtual(5) for details.
+
Improvements compared to Postfix 1.1
Postfix 2.0 address classes made the following improveme
* There is no mail delivery transport parameter. Every address must be
> aliased to some other address.
>
> + * Note: unlike other classes' maps, virtual_alias_maps is not used solely
> for
> +domains listed in virtual_alias_domains. See the section on VIRTUAL
>
r address.
+ * Note: unlike other classes' maps, virtual_alias_maps is not used solely for
+domains listed in virtual_alias_domains. See the section on VIRTUAL ALIAS
DOMAINS
+in virtual(5) for details.
+
The virtual mailbox domain class.
* Purpose: final delivery for hosted d
ter. Every address must be
> aliased to some other address.
>
> + * Note: virtual_alias_maps will be consulted (and its results applied) by
> +all address classes unless a given domain is listed in
> virtual_alias_domains.
> +See the section on VIRTUAL ALIAS DOMAIN
On Apr 10, 2012, at 10.44, /dev/rob0 wrote:
>> + * Note: virtual_alias_maps will be used with other address classes unless
>> +a given domain is listed in virtual_alias_domains. see the section on
>
> To me, this confuses things more. virtual_alias_maps will be
> consu
On Tue, Apr 10, 2012 at 09:36:42AM -0400, btb wrote:
> On 2012.04.10 08.32, Wietse Venema wrote:
> >>so the relationship between virtual_alias_maps/
> >>virtual_alias_domains is not quite the same as the relationship
> >>between virtual_mailbox_m
On 2012.04.10 08.32, Wietse Venema wrote:
so the relationship between virtual_alias_maps/virtual_alias_domains is
not quite the same as the relationship between
virtual_mailbox_maps/virtual_mailbox_domains or
relay_recipients/relay_domains?
This is documented in virtual(5).
thanks for the
alias_maps, those related domains would need
> >>to be listed in virtual_alias_domains.
> >
> >This assumption is incorrect. All recipients, regardless of
> >address class are subject to virtual(5) rewriting.
>
> so the relationship between virtual_alias_maps/
virtual_alias_maps, those related domains would need to be listed in
> >> virtual_alias_domains.
> >
> > This assumption is incorrect. All recipients, regardless of address
> > class are subject to virtual(5) rewriting.
>
> so the relationship between virtual_alias_maps/
On 2012.04.09 23.32, Viktor Dukhovni wrote:
On Mon, Apr 09, 2012 at 10:21:05PM -0400, b...@bitrate.net wrote:
Given my understanding of address classes, it seemed that in order to use
virtual_alias_maps, those related domains would need to be listed in
virtual_alias_domains.
This assumption
On Mon, Apr 09, 2012 at 10:21:05PM -0400, b...@bitrate.net wrote:
> Given my understanding of address classes, it seemed that in order to use
> virtual_alias_maps, those related domains would need to be listed in
> virtual_alias_domains.
This assumption is incorrect. All recipients, r
why.
given my understanding of address classes, it seemed that in order to use
virtual_alias_maps, those related domains would need to be listed in
virtual_alias_domains. yet the same domains would also need to be listed in
relay_domains in order to use the relay domain class, and i know listing t
aintain a
list of domains in multiple places. info@ is a business
requirement, and you are right that I could add abuse@,
and postmaster@ as suggested below.
> Same as "virtual_alias_domains = static:yes".
Yes, I actually tried that.
> > virtual_alias_maps = pcre:${config_d
On 3/10/2012 10:29 AM, Allan Wind wrote:
> On 2012-03-10 07:25:42, Wietse Venema wrote:
>> No surprise, that mail delivery fails: all your domains are hijacked
>> by the virtual_alias_domains address class, and you define only one
>> user name there.
>>
>
On 2012-03-10 07:25:42, Wietse Venema wrote:
> No surprise, that mail delivery fails: all your domains are hijacked
> by the virtual_alias_domains address class, and you define only one
> user name there.
>
> See: http://www.postfix.org/ADDRESS_CLASS_README.html
I read over t
s? Why all domains
and why only info@? This does not make much sense.
> Figured this could be done with 2.7.1 using:
>
> virtual_alias_domains = pcre:${config_directory}/virtual_alias_domains
>
> /.*/ anything
Same as "virtual_alias_domains = static:yes"
Allan Wind:
> I have an odd requirement of redirecting info@ for a reasonable
> large number of domains to i...@example.com. Figured
> this could be done with 2.7.1 using:
>
> virtual_alias_domains = pcre:${config_directory}/virtual_alias_domains
>
> /.*/ anything
This mak
I have an odd requirement of redirecting info@ for a reasonable
large number of domains to i...@example.com. Figured
this could be done with 2.7.1 using:
virtual_alias_domains = pcre:${config_directory}/virtual_alias_domains
/.*/ anything
virtual_alias_maps = pcre:${config_directory
Le 23/11/2010 21:19, Andrew Beverley a écrit :
On Tue, 2010-11-23 at 13:21 -0600, Noel Jones wrote:
There is nothing significant wrong with your config -- postfix
is working correctly and performing the queries required.
My only suggestion is to be careful what you put in the
"access" table und
straints cannot be used to store the list of
> > > virtual_alias_domains, virtual_mailbox_domains, ... Not a problem,
> > > since after hardcoding the candidate domains in the table definition,
> > > there is really no point in using a database at all, just list the
> > > domains in main.
oticed that my Postfix (version 2.3.8) is performing a
> >>> virtual_alias_maps mysql database query for every email that it is
> >>> processing, even if the domain is not listed in virtual_alias_domains.
> >>>
> >>> So for example, I have andybev.com i
On Tue, Nov 23, 2010 at 06:53:44PM +, Andrew Beverley wrote:
> > Note, that the above applies also to "bare" domain queries, so tables
> > with "domain =" constraints cannot be used to store the list of
> > virtual_alias_domains, virtual_mailbox_domai
, even if the domain is not listed in virtual_alias_domains.
So for example, I have andybev.com in virtual_alias_domains and a
database query set up for virtual_alias_maps. When I send an email
*from* the server to an external email address, then that recipient (eg
joeblo...@hotmail.com) gets looked up
>> virtual_alias_maps mysql database query for every email that it is
> >> processing, even if the domain is not listed in virtual_alias_domains.
>
> This is correct behaviour. The rewriting performed by virtual(5) is
> documented and intended to apply to *all* addresses.
even if the domain is not listed in virtual_alias_domains.
> >
> > So for example, I have andybev.com in virtual_alias_domains and a
> > database query set up for virtual_alias_maps. When I send an email
> > *from* the server to an external email address, then that recip
essing, even if the domain is not listed in virtual_alias_domains.
This is correct behaviour. The rewriting performed by virtual(5) is
documented and intended to apply to *all* addresses.
If you have an SQL or LDAP table that stores data for only a specific
set of domains, you can use the "d
On 11/21/2010 4:40 PM, Andrew Beverley wrote:
Hi,
I have noticed that my Postfix (version 2.3.8) is performing a
virtual_alias_maps mysql database query for every email that it is
processing, even if the domain is not listed in virtual_alias_domains.
So for example, I have andybev.com in
Hi,
I have noticed that my Postfix (version 2.3.8) is performing a
virtual_alias_maps mysql database query for every email that it is
processing, even if the domain is not listed in virtual_alias_domains.
So for example, I have andybev.com in virtual_alias_domains and a
database query set up for
Le 18/10/2010 22:56, Jerrale G a écrit :
On 10/18/2010 4:43 PM, Jeroen Geilman wrote:
On 10/18/2010 10:36 PM, Jerrale G wrote:
On 10/18/2010 4:29 PM, The Doctor wrote:
REcently I have noted that virtual_alias_domains is growing.
Is their some way for main.cf to look a file up instead of
On 10/18/2010 10:56 PM, Jerrale G wrote:
On 10/18/2010 4:43 PM, Jeroen Geilman wrote:
On 10/18/2010 10:36 PM, Jerrale G wrote:
On 10/18/2010 4:29 PM, The Doctor wrote:
REcently I have noted that virtual_alias_domains is growing.
Is their some way for main.cf to look a file up instead of
Le 18/10/2010 22:29, The Doctor a écrit :
REcently I have noted that virtual_alias_domains is growing.
Is their some way for main.cf to look a file up instead of
having to read a whole line?
http://www.postfix.org/postconf.5.html#virtual_alias_domains
states:
"
Specify a list of ho
On 10/18/2010 4:43 PM, Jeroen Geilman wrote:
On 10/18/2010 10:36 PM, Jerrale G wrote:
On 10/18/2010 4:29 PM, The Doctor wrote:
REcently I have noted that virtual_alias_domains is growing.
Is their some way for main.cf to look a file up instead of
having to read a whole line?
You are
On Mon, Oct 18, 2010 at 04:36:21PM -0400, Jerrale G wrote:
> On 10/18/2010 4:29 PM, The Doctor wrote:
>> REcently I have noted that virtual_alias_domains is growing.
>>
>> Is their some way for main.cf to look a file up instead of
>> having to read a whole line?
>
On 10/18/2010 10:36 PM, Jerrale G wrote:
On 10/18/2010 4:29 PM, The Doctor wrote:
REcently I have noted that virtual_alias_domains is growing.
Is their some way for main.cf to look a file up instead of
having to read a whole line?
You are limited to using mysql, ONE file, ldap, postgresql
On 10/18/2010 4:29 PM, The Doctor wrote:
REcently I have noted that virtual_alias_domains is growing.
Is their some way for main.cf to look a file up instead of
having to read a whole line?
You are limited to using mysql, ONE file, ldap, postgresql, or mssql for
each virtual_*_* parameter
REcently I have noted that virtual_alias_domains is growing.
Is their some way for main.cf to look a file up instead of
having to read a whole line?
--
Member - Liberal International This is doc...@nl2k.ab.ca Ici doc...@nl2k.ab.ca
God, Queen and country! Never Satan President Republic! Beware
M.S. Lucas:
> Hello,
>
> Is there a "default" name for storing all the alias domain domainnames?
>
> I know you can create your own name but I want to use a more standard used
> name for it
>
> virtual_alias_domains = /etc/postfix/aliasdomains
>
This deep sec
Hello,
Is there a "default" name for storing all the alias domain domainnames?
I know you can create your own name but I want to use a more standard used
name for it
virtual_alias_domains = /etc/postfix/aliasdomains
With kind regards,
Maurice Lucas
On Wed, Dec 30, 2009 at 11:49:24PM +0100, Philippe Cerfon wrote:
> When havin a domain that hast just aliases on no real maliboxes, on
> could either use virtual_alias_domains or virtual_mailbox_domains and
> in the later case simply not creating any mailboxes but just
> configuring
Hi.
When havin a domain that hast just aliases on no real maliboxes, on
could either use virtual_alias_domains or virtual_mailbox_domains and
in the later case simply not creating any mailboxes but just
configuring addresses in virtual_alias_maps.
Is there any performance benfit or something
gister for some.example.com is the MS Exange server. Since
virtual_alias_domains is not defined, I suppose that every time an
email is sent to someb...@example.com, a lookup in the ldap directory
is performed. If I set virtual_alias_domains to example.com (or any
other domains I serve), wouldn't this be e
gister for some.example.com is the MS Exange server. Since
virtual_alias_domains is not defined, I suppose that every time an
email is sent to someb...@example.com, a lookup in the ldap directory
is performed. If I set virtual_alias_domains to example.com (or any
other domains I serve), wouldn't this be e
; the user part of the email address plus a date field like this:
> mail2news-mmdd-alt.test.newsgr...@m2n.mydomain .
> I have a main domain name mydomain.com and i have made a subdomain
> m2n.mydomain.com and i have included both in a virtual_alias_domains . I
> have configured
field like this:
mail2news-mmdd-alt.test.newsgr...@m2n.mydomain .
I have a main domain name mydomain.com and i have made a subdomain
m2n.mydomain.com and i have included both in a virtual_alias_domains . I
have configured also the vitual_maps with a catch-all domain entry like
@m2n.mydomain
77 matches
Mail list logo
