On 13.03.2013 14:40, DTNX Postmaster wrote:
> On Mar 13, 2013, at 11:37, Gerald Vogt <v...@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

Reply via email to