Virtual domain and masquerading

[Gerald Vogt]

Hi!

I am trying to set up mail relays for our domain. Basically, the relays
should only "route" e-mails to their destination. They are not supposed
to deliver any e-mails locally. Relays are also supposed to masquerade
server names. All mail accounts for our domain reside on a central
mailbox server.

For example, if example.com is our domain:

us...@example.com
us...@server.example.com

should go to mailbox server mailbox.example.com (i.e.
us...@mailbox.example.com)

All other domains are routed as usual via MX records to the internet.

Of course, I want the server to refuse non-existing mail accounts, thus
I have a virtual_alias_map which contains mappings for all existing
accounts.

My problem now is that this works fine for e-mails sent from the relay
itself. The relay will accept mails for us...@example.com and
us...@server.example.com and will correctly forward it to the mailbox. It
will also refuse to accept mails to non-existing addresses, e.g.
te...@example.com and te...@server.example.com

However, for e-mails arriving from outside of our network the relays
won't accept e-mails going to any address containing the server name
because it's not listed in the virtual_alias_map.

It will accept us...@example.com but deny us...@server.example.com with an
554 relay access denied.

So it seems postfix does the relay checks first and will only do
masquerading after that. I have tried many things but to no avail. There
seems to be no way around this.

Anyone has a suggestion how to handle this?

Thanks,

Gerald

postconf -n of a test relay with a minimal config:

alias_database =
alias_maps =
canonical_maps = hash:/etc/postfix/canonical
config_directory = /etc/postfix
local_header_rewrite_clients = static:all
masquerade_classes = envelope_recipient
masquerade_domains = example.com
mydestination =
mynetworks = 127.0.0.0/8
relayhost =
virtual_alias_domains = example.com
virtual_alias_maps = hash:/etc/postfix/virtual

/etc/postfix/virtual:

us...@example.com us...@mailbox.example.com
first...@example.com us...@mailbox.example.com

[James Griffin]

[--------- Wed 13.Mar'13 at 10:47:09 +0100 Gerald Vogt :---------]

Perhaps you should add the fqdn to $virtual_alias_domains. I just looked at this from here:

http://www.postfix.org/VIRTUAL_README.html


--
James Griffin: jmz at kontrol.kode5.net
jmzgriffin at gmail.com

A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38

[Gerald Vogt]

On 13.03.2013 11:07, James Griffin wrote:
>> virtual_alias_domains = example.com
>> virtual_alias_maps = hash:/etc/postfix/virtual
>>
>> /etc/postfix/virtual:
>>
>> us...@example.com us...@mailbox.example.com
>> first...@example.com us...@mailbox.example.com
>
> Perhaps you should add the fqdn to $virtual_alias_domains. I just looked at this from here:

Which FQDN? The relay? Or of all my servers?

> http://www.postfix.org/VIRTUAL_README.html

I don't see an example there which suggests to add anything else but a
domain name to virtual_alias_domains.

-Gerald

[DTNX Postmaster]

> virtual_alias_domains = example.com
> virtual_alias_maps = hash:/etc/postfix/virtual
>
> /etc/postfix/virtual:
>
> us...@example.com us...@mailbox.example.com
> first...@example.com us...@mailbox.example.com

Masquerading is intended for outgoing only, AFAIK, see;
http://www.postfix.org/postconf.5.html#masquerade_domains

Why not use 'transport_maps', if you are not delivering any mail
locally?

example.com relay:[mailbox.example.com]

You can relay the server name addresses in a similar fashion;

server.example.com relay:[mailbox.example.com]

Or use 'recipient_canonical_maps' to rewrite;

@server.example.com @example.com

Which will then be routed to 'mailbox.example.com' using the transport
maps. The latter means that the backend server does not need to know
about 'server.example.com'.

When combined with address verification this also removes the need to
maintain a list of valid accounts on the relay server itself, since it
will check if an account exists before accepting mail for it.

Cya,
Jona

[Gerald Vogt]

On 13.03.2013 11:29, DTNX Postmaster wrote:
> Masquerading is intended for outgoing only, AFAIK, see;
> http://www.postfix.org/postconf.5.html#masquerade_domains
>
> Why not use 'transport_maps', if you are not delivering any mail
> locally?
>
> example.com relay:[mailbox.example.com]
>
> You can relay the server name addresses in a similar fashion;
>
> server.example.com relay:[mailbox.example.com]

That does not really scale well as it is some 100+ servers with servers
coming and going.

> Or use 'recipient_canonical_maps' to rewrite;
>
> @server.example.com @example.com

Same here.

> Which will then be routed to 'mailbox.example.com' using the transport
> maps. The latter means that the backend server does not need to know
> about 'server.example.com'.
>
> When combined with address verification this also removes the need to
> maintain a list of valid accounts on the relay server itself, since it
> will check if an account exists before accepting mail for it.

Due to the amount of mail accounts address verification isn't really an
option. We have a list of mail accounts ready thus it should be checked
locally on the relay before accepting the e-mails.

-Gerald

[DTNX Postmaster]

On Mar 13, 2013, at 11:37, Gerald Vogt <vo...@spamcop.net> wrote:

> On 13.03.2013 11:29, DTNX Postmaster wrote:
>> Masquerading is intended for outgoing only, AFAIK, see;
>> http://www.postfix.org/postconf.5.html#masquerade_domains
>>
>> Why not use 'transport_maps', if you are not delivering any mail
>> locally?
>>
>> example.com relay:[mailbox.example.com]
>>
>> You can relay the server name addresses in a similar fashion;
>>
>> server.example.com relay:[mailbox.example.com]
>
> That does not really scale well as it is some 100+ servers with servers
> coming and going.
>
>> Or use 'recipient_canonical_maps' to rewrite;
>>
>> @server.example.com @example.com
>
> Same here.

A hundred or so servers shouldn't really be any problem in terms of
scale, for either of these options. Our transport map contains over two
hundred, for example, and we're a small operation.

Servers coming and going shouldn't be a problem either, can be scripted
based on addition and removal of DNS records, for example. The exact
method depends on your setup and preference, of course. YMMV.

But regardless if which option you pick, you will need to tell the
relay that 'server.example.com' is something that is considered 'local'
for incoming mail, otherwise you will get that 'relay access denied'
error.

>> Which will then be routed to 'mailbox.example.com' using the transport
>> maps. The latter means that the backend server does not need to know
>> about 'server.example.com'.
>>
>> When combined with address verification this also removes the need to
>> maintain a list of valid accounts on the relay server itself, since it
>> will check if an account exists before accepting mail for it.
>
> Due to the amount of mail accounts address verification isn't really an
> option. We have a list of mail accounts ready thus it should be checked
> locally on the relay before accepting the e-mails.

You didn't give any specifics, so you get a generic answer, with
several options. If you feel that having a generated list with
'example.com' mail addresses suits you better, that's fine.

But as said above, you will need to provide Postfix with a list of
domains for which it is responsible, if you want to accept mail for it.

Cya,
Jona

[Gerald Vogt]

On 13.03.2013 14:40, DTNX Postmaster wrote:
> On Mar 13, 2013, at 11:37, Gerald Vogt <vo...@spamcop.net> wrote:
>
>> On 13.03.2013 11:29, DTNX Postmaster wrote:
>>> Masquerading is intended for outgoing only, AFAIK, see;
>>> http://www.postfix.org/postconf.5.html#masquerade_domains
>>>
>>> Why not use 'transport_maps', if you are not delivering any mail
>>> locally?
>>>
>>> example.com relay:[mailbox.example.com]
>>>
>>> You can relay the server name addresses in a similar fashion;
>>>
>>> server.example.com relay:[mailbox.example.com]
>>
>> That does not really scale well as it is some 100+ servers with servers
>> coming and going.
>>
>>> Or use 'recipient_canonical_maps' to rewrite;
>>>
>>> @server.example.com @example.com
>>
>> Same here.
>
> A hundred or so servers shouldn't really be any problem in terms of
> scale, for either of these options. Our transport map contains over two
> hundred, for example, and we're a small operation.
>
> Servers coming and going shouldn't be a problem either, can be scripted
> based on addition and removal of DNS records, for example. The exact
> method depends on your setup and preference, of course. YMMV.

It can't be scripted. Servers don't necessarily go into the DNS.

> But regardless if which option you pick, you will need to tell the
> relay that 'server.example.com' is something that is considered 'local'
> for incoming mail, otherwise you will get that 'relay access denied'
> error.

Any hostname/subdomain under example.com is local. That's what I want to
tell postfix. And that regardless of what comes after the @ but in our
domain, I know all the names which can appear before the @.

IMHO, that should not require to list all possible server names...

>>> Which will then be routed to 'mailbox.example.com' using the transport
>>> maps. The latter means that the backend server does not need to know
>>> about 'server.example.com'.
>>>
>>> When combined with address verification this also removes the need to
>>> maintain a list of valid accounts on the relay server itself, since it
>>> will check if an account exists before accepting mail for it.
>>
>> Due to the amount of mail accounts address verification isn't really an
>> option. We have a list of mail accounts ready thus it should be checked
>> locally on the relay before accepting the e-mails.
>
> You didn't give any specifics, so you get a generic answer, with
> several options. If you feel that having a generated list with
> 'example.com' mail addresses suits you better, that's fine.

I have stripped down the configuration for testing as far as possible.
The full configuration is much more complex. But still to demonstrate
this problem that posted config is enough. That's why I posted it.

> But as said above, you will need to provide Postfix with a list of
> domains for which it is responsible, if you want to accept mail for it.

Postfix is responsible for example.com and any subdomain of example.com.
It shouldn't be necessary to list all subdomains to make the server
responsible.

And regardless which hostname/domainname you have in your recipient
address, it should all map to @example.com. And all this works except
for the failing relay check because the relay checks happens before
masquerading for SMTP mails unlike mails originating on the relay.

And for the mailbox server this also works fine: it accepts any
subdomain of example.com and still delivers the mail to the correct user
mailbox and is able to reject recipient addresses which don't exist.

So the concept should be impossible.

-Gerald

[Wietse Venema]

Gerald Vogt:

> Any hostname/subdomain under example.com is local. That's what I want to
> tell postfix. And that regardless of what comes after the @ but in our
> domain, I know all the names which can appear before the @.
>
> IMHO, that should not require to list all possible server names...

Use a regexp.

/etc/postfix/main.cf:
relay_domains = pcre:/etc/postfix/relay.pcre
relay_recipient_maps = some database...

/etc/postfix/relay.pcre:
/\.example\.com$/ whatever

It's unsafe to leave relay_recipient_maps empty when you're
receiving mail from the internet.

Wietse

[Gerald Vogt]

On 13.03.2013 15:22, Wietse Venema wrote:
> Gerald Vogt:
>> Any hostname/subdomain under example.com is local. That's what I want to
>> tell postfix. And that regardless of what comes after the @ but in our
>> domain, I know all the names which can appear before the @.
>>
>> IMHO, that should not require to list all possible server names...
>
> Use a regexp.
>
> /etc/postfix/main.cf:
> relay_domains = pcre:/etc/postfix/relay.pcre
> relay_recipient_maps = some database...
>
> /etc/postfix/relay.pcre:
> /\.example\.com$/ whatever

1. As far as I understand the documentation,
relay_domains = example.com
already accepts all mail for subdomains. A regex is not necessary.

2. This still won't help to accept e-mails for users regardless of what
comes after the @ and reject it if the user does not exist.

-Gerald

[Wietse Venema]

Gerald Vogt:

> On 13.03.2013 15:22, Wietse Venema wrote:
> > Gerald Vogt:
> >> Any hostname/subdomain under example.com is local. That's what I want to
> >> tell postfix. And that regardless of what comes after the @ but in our
> >> domain, I know all the names which can appear before the @.
> >>
> >> IMHO, that should not require to list all possible server names...
> >
> > Use a regexp.
> >
> > /etc/postfix/main.cf:
> > relay_domains = pcre:/etc/postfix/relay.pcre
> > relay_recipient_maps = some database...
> >
> > /etc/postfix/relay.pcre:
> > /\.example\.com$/ whatever
>
> 1. As far as I understand the documentation,
> relay_domains = example.com
> already accepts all mail for subdomains. A regex is not necessary.

Agreed. The regexp is a tool for more complicated scenarios.

> 2. This still won't help to accept e-mails for users regardless of what
> comes after the @ and reject it if the user does not exist.

To reject non-existent recipients, list the existing ones in
relay_recipient_maps. If you can't populate that table, use
reject_unverified_recipient with Postfix's verify cache. The cache
will optimize out common lookups, but not dictionary attacks or
backscatter mail.

Wietse

[Gerald Vogt]

On 13.03.2013 15:54, Wietse Venema wrote:
>> 2. This still won't help to accept e-mails for users regardless of what
>> comes after the @ and reject it if the user does not exist.
>
> To reject non-existent recipients, list the existing ones in
> relay_recipient_maps. If you can't populate that table, use

And how do I create a list to accept e-mails for us...@example.com and
user@*.example.com for a known set of user names?

-Gerald

[Wietse Venema]

Gerald Vogt:

In that case one should normalize the address (us...@whatever.example.com
-> us...@example.com) before consulting a table with all us...@example.com.

Unfortunately, Postfix has (up to now) no way to feed the result
from one table into another table, but there is a workaround
which requires Postfix 2.7 or later:

/etc/postfix/main.cf:
smtpd_command_filter = pcre:/etc/postfix/command_filter

/etc/postfix/command_filter:
/^RCPT\s+TO:\s*<([^@]+)@.+\.example\.com>(.*)/ RCPT TO:<${1...@example.com>$2

(address forms without <> left as an exercise for the reader).

This normalizes us...@whatever.example.com -> us...@example.com before
the SMTP server subjects the address to recipient validion, with all
valid us...@example.com instances listed with relay_recipient_maps.

This is admittely a bit gross but so is the problem.

Wietse

[Gerald Vogt]

On 13.03.2013 16:22, Wietse Venema wrote:
> Gerald Vogt:
>> On 13.03.2013 15:54, Wietse Venema wrote:
>>>> 2. This still won't help to accept e-mails for users regardless of what
>>>> comes after the @ and reject it if the user does not exist.
>>>
>>> To reject non-existent recipients, list the existing ones in
>>> relay_recipient_maps. If you can't populate that table, use
>>
>> And how do I create a list to accept e-mails for us...@example.com and
>> user@*.example.com for a known set of user names?
>
> In that case one should normalize the address (us...@whatever.example.com
> -> us...@example.com) before consulting a table with all us...@example.com.

I thought that's what masquerading is for.

http://www.postfix.org/ADDRESS_REWRITING_README.html#masquerade

But unfortunately that's not done before the recipient address check.

> Unfortunately, Postfix has (up to now) no way to feed the result
> from one table into another table, but there is a workaround
> which requires Postfix 2.7 or later:

Too bad. I have a Centos 6 with postfix 2.6.6

> This is admittely a bit gross but so is the problem.

What's so gross about the problem? It's basic masquerading. It just
should be done before check the recipient address and not after...

-Gerald

[Noel Jones]

On 3/13/2013 10:22 AM, Wietse Venema wrote:
> Gerald Vogt:
>> On 13.03.2013 15:54, Wietse Venema wrote:
>>>> 2. This still won't help to accept e-mails for users regardless of what
>>>> comes after the @ and reject it if the user does not exist.
>>>
>>> To reject non-existent recipients, list the existing ones in
>>> relay_recipient_maps. If you can't populate that table, use
>>
>> And how do I create a list to accept e-mails for us...@example.com and
>> user@*.example.com for a known set of user names?
>
> In that case one should normalize the address (us...@whatever.example.com
> -> us...@example.com) before consulting a table with all us...@example.com.
>

> Unfortunately, Postfix has (up to now) no way to feed the result
> from one table into another table, but there is a workaround
> which requires Postfix 2.7 or later:
>

> /etc/postfix/main.cf:
> smtpd_command_filter = pcre:/etc/postfix/command_filter
>
> /etc/postfix/command_filter:
> /^RCPT\s+TO:\s*<([^@]+)@.+\.example\.com>(.*)/ RCPT TO:<${1...@example.com>$2
>
> (address forms without <> left as an exercise for the reader).
>
> This normalizes us...@whatever.example.com -> us...@example.com before
> the SMTP server subjects the address to recipient validion, with all
> valid us...@example.com instances listed with relay_recipient_maps.
>

> This is admittely a bit gross but so is the problem.
>

> Wietse
>


An alternative is to put the recipients in an sql table and use a
relay_recipient_maps query that ignores or wildcards the domain name.

This requires a postfix built with *sql support.



-- Noel Jones

[Wietse Venema]

Gerald Vogt:

> > Unfortunately, Postfix has (up to now) no way to feed the result
> > from one table into another table, but there is a workaround
> > which requires Postfix 2.7 or later:
>

> Too bad. I have a Centos 6 with postfix 2.6.6

That's a 4-year old code base. It was unfortunately not possible
for me to release Postfix with all the features that you might need
all at once.

> > This is admittely a bit gross but so is the problem.
>

> What's so gross about the problem? It's basic masquerading. It just
> should be done before check the recipient address and not after...

It's unusual enough that 4-year old Postfix doesn't do address munging
before recipient validation (though some MySQL plumbing can do the
job if you can ignore the @domain portion, as suggested by Noel).

Analogous to Noel's suggestion, one possibility is that you list
bare usernames (without @example.com etc.) in relay_recipient_maps.
It's not documented, but I could add that note since the behavior is
not going to change.

Wietse

[Gerald Vogt]

On 13.03.2013 11:29, DTNX Postmaster wrote:
> Masquerading is intended for outgoing only, AFAIK, see;
> http://www.postfix.org/postconf.5.html#masquerade_domains

According to this:

http://www.postfix.org/ADDRESS_REWRITING_README.html#receiving

masquerading is done when mail is received.

But smtpd doesn't recognize masquerading. Masquerading is done in the
following step by cleanup. Too bad.

-Gerald

[Wietse Venema]

Wietse Venema:

This requires that the @domain matches mydestination, so that is
unlikely to work.

Wietse

[Viktor Dukhovni]

On Wed, Mar 13, 2013 at 12:58:16PM -0400, Wietse Venema wrote:

> > Analogous to Noel's suggestion, one possibility is that you list
> > bare usernames (without @example.com etc.) in relay_recipient_maps.
> > It's not documented, but I could add that note since the behavior is
> > not going to change.
>
> This requires that the @domain matches mydestination, so that is
> unlikely to work.

One can list all the relay domains in mydestination, configure
local_recipient_maps (instead of relay_recipient_maps) as specified,
and then either:

main.cf:
remap = pcre:${config_directory}/
indexed = ${default_database_type}:${config_directory}/

local_transport = relay:[relay.example.com]
local_recipient_maps = ${indexed}usernames
transport_maps = ${indexed}transport
mydestination = ${remap}localdomains.re

localdomains.re:
/(^|\.)example\.com$/ LOCAL

usernames:
larry LOCAL
curly LOCAL
moe LOCAL

transport:
# Optional exceptions to inbound relaying of local mail.
# localhost local
# hostname.example.com local
# ...

Since the OP has a completely flat namespace, there is unlikely to
be any difference between the parent example.com domain and its
"relay" children.

This recipe is not "rigid", there is some room for additional tweaks
if the requirements are more complex.

For my $0.02, I abandoned inbound masquerading a long time ago,
who needs every email address of the form:

us...@your-mother-has-big-email-addresses.example.com

I masquerade sender addresses at the internal MSA so only the
primary addresses of users leak out to the outside world, and *only*
accept primary addresses. Inbound masquerading is a legacy of
times long gone by. The fact that Postfix supports for this is a
bit clunky is more of a signal about the feature than about Postfix.

[ Admittedly, it would probably be helpful to have some 1-to-1 rewriting
support in smtpd(8) that happens before address validation. That
would make the wildcard canonical maps folks happy, and inadvertantly
"fix" masquerading. ]

--
Viktor.

[Gerald Vogt]

On 13.03.2013 16:51, Noel Jones wrote:
> An alternative is to put the recipients in an sql table and use a
> relay_recipient_maps query that ignores or wildcards the domain name.

Well, I have got my test server relaying with a pcre table for the
relay_recipients. It looks ugly but works for mails relayed through smtp.

The only problem now are e-mails which are sent from the relay itself
via sendmail. Relay checks don't apply and it will accept any address.
Which recipient_map applies to e-mails send via sendmail?

-Gerald

Current config:

# postconf -n

alias_database =
alias_maps =
canonical_maps = hash:/etc/postfix/canonical
config_directory = /etc/postfix
local_header_rewrite_clients = static:all
masquerade_classes = envelope_recipient
masquerade_domains = example.com
mydestination =
mynetworks = 127.0.0.0/8

relay_domains = .example.com example.com
relay_recipient_maps = pcre:/etc/postfix/relay_recipients.pcre
relayhost =
transport_maps = hash:/etc/postfix/transport
virtual_alias_maps = hash:/etc/postfix/virtual

# cat relay_recipients.pcre
/^user\@(.*\.)?example\.com$/ OK
/^first\.last\@(.*\.)?example\.com$/ OK

/^extusername\@(.*\.)?example\.com$/ OK

# cat virtual
extus...@example.com some...@elsewhere.example.org

[Gerald Vogt]

On 13.03.2013 18:51, Viktor Dukhovni wrote:
> For my $0.02, I abandoned inbound masquerading a long time ago,
> who needs every email address of the form:
>
> us...@your-mother-has-big-email-addresses.example.com
>
> I masquerade sender addresses at the internal MSA so only the
> primary addresses of users leak out to the outside world, and *only*
> accept primary addresses. Inbound masquerading is a legacy of
> times long gone by. The fact that Postfix supports for this is a
> bit clunky is more of a signal about the feature than about Postfix.

I have set up postfix on all my servers with a null client configuration:

mydestination =
relayhost = $mydomain

It seems easier to me to keep the configuration on 100+ servers as
simple as possible and do all the rewriting on the central relays. Seems
to be the better approach to me. That's why I came up with this.

-Gerald

[Wietse Venema]

Gerald Vogt:

> The only problem now are e-mails which are sent from the relay itself
> via sendmail. Relay checks don't apply and it will accept any address.
> Which recipient_map applies to e-mails send via sendmail?

There is no "receive time" address validation for sendmail submission.

Wietse

[DTNX Postmaster]

Solve the problem at the source; masquerade on each individual server,
and avoid jumping through hoops on the central relay.

Easier to maintain. Scales better, too.

Cya,
Jona

[Gerald Vogt]

On 14.03.2013 12:10, DTNX Postmaster wrote:
>> It seems easier to me to keep the configuration on 100+ servers as
>> simple as possible and do all the rewriting on the central relays. Seems
>> to be the better approach to me. That's why I came up with this.
>
> Solve the problem at the source; masquerade on each individual server,
> and avoid jumping through hoops on the central relay.
>
> Easier to maintain. Scales better, too.

IMHO, maintaining consistent postfix configurations on 100+ servers is
definitively harder than a handful of relay servers with a fixed
configuration on the other servers.

-Gerald

[Ansgar Wiechers]

That's what configuration management was invented for. You may want to
look into puppet et al.

Regards
Ansgar Wiechers
--
"Abstractions save us time working, but they don't save us time learning."
--Joel Spolsky

[Viktor Dukhovni]

On Thu, Mar 14, 2013 at 03:19:59PM +0100, Ansgar Wiechers wrote:

> On 2013-03-14 Gerald Vogt wrote:
> > On 14.03.2013 12:10, DTNX Postmaster wrote:
> >>> It seems easier to me to keep the configuration on 100+ servers as
> >>> simple as possible and do all the rewriting on the central relays.
> >>> Seems to be the better approach to me. That's why I came up with
> >>> this.
> >>
> >> Solve the problem at the source; masquerade on each individual
> >> server, and avoid jumping through hoops on the central relay.
> >>
> >> Easier to maintain. Scales better, too.
> >
> > IMHO, maintaining consistent postfix configurations on 100+ servers is
> > definitively harder than a handful of relay servers with a fixed
> > configuration on the other servers.
>
> That's what configuration management was invented for. You may want to
> look into puppet et al.

There's nothing to manage, just set "myorigin = $mydomain" on each
null client, and enable masquerading there. Null clients only
receive mail from local submission (and loopback:25) so doing
masquerading there is safe and natural.

The MULTI_INSTANCE_README.html document happens to contain a
reasonaly complete null-client recipe, start there and tweak to
requirements. Once configured, these stay stable.

As for mailhubs, my advice is to separate the MSA mailhub
(the one the null clients are configured to sent to), from
the MTA mailhub (the one routing internal mail to various
mailbox servers and to the outside).

The MSA mailhub can also do masquerading safely, and recipient
validation is not an issue there, it does not receive mail from
outside.

All this assumes an organization large enough that masquerading is
of some interest in the first place, and you have lots of sub-domains,
and multiple IP addresses to play with to deploy dedicated service
endpoints.

--
Viktor.

[Gerald Vogt]

On 14.03.2013 21:19, Viktor Dukhovni wrote:
> There's nothing to manage, just set "myorigin = $mydomain" on each
> null client, and enable masquerading there. Null clients only
> receive mail from local submission (and loopback:25) so doing
> masquerading there is safe and natural.

Well, it's not that simple. In fact, I don't want to masquerade
everything in example.com but most except a few servers which require
e-mails (list servers, some for historical reasons...) This list may
change...

-Gerald