Re: Processing order of canonical maps

2016-09-16 Thread Todd C. Olson
As a new administrator of postfix I am not able to determine which of the two 
orders is correct from the existing documentation.  An additional sentence 
would be very helpful.  Perhaps, under canonical(5) section "TABLE SEARCH 
ORDER":  "Each pattern is looked for across the entire set of tables in the map 
before moving on to the next pattern"

Regards,
Todd

> On Fr, 2016-09-16, at 08:33, Ondřej Lysoněk <olyso...@redhat.com> wrote:
> 
> It just doesn't seem very clear to me. And one of our customers even got the 
> wrong impression about the search order. I think a sentence like the 
> following could be dropped in there somewhere: "First, a match of 
> 'user@domain' is searched for across all the listed tables in the order the 
> tables are listed. If no match is found, a match of 'user' is searched for in 
> all the listed tables, and so on". Or something less horrible.
> 
> Ondra
> 
> On 09/16/2016 12:51 PM, Wietse Venema wrote:
>> canonical(5) section "TABLE SEARCH ORDER":
>> 
>>"With lookups from indexed files such as DB or DBM,  or  from
>>networked tables  such  as  NIS,  LDAP or SQL, patterns are tried
>>in the order as listed below:"
>> 
>> That really does what it says: try the first query.  Try the second
>> query. And so on.
>> 
>> postconf(5) section "canonical_maps":
>> 
>>"Tables will be searched in the specified order until a match
>> is found.  Note: these lookups are recursive."
>> 
>> That really works as described. For each query, search the first
>> table. Try the second table. And so on.
>> 
>> The information is in two places, but it is not ambiguous.
>> 
>> Are you proposing to mix these descriptions?
>> 
>>  Wietse
>> 
>> Ond?ej Lyson?k:
>> [ Charset windows-1252 converted... ]
>>> Thank you!
>>> 
>>> The documentation seems a bit ambiguous on this topic. After reading
>>> canonical(5) and the canonical_maps section of postconf(5), I think it's
>>> not clear which of the processing orders, mentioned in the first email,
>>> it actually uses. Would you like me to write a patch for this?
>>> 
>>> Ondra
>>> 
>>> 
>>> On 09/15/2016 03:46 PM, Wietse Venema wrote:
>>>> Ond?ej Lyson?k:
>>>>> Hi,
>>>>> 
>>>>> I need some help configuring canonical maps.
>>>>> 
>>>>> Suppose you have two lookup tables listed in canonical_maps and each of
>>>>> these tables uses all three pattern types (user@domain, user, @domain).
>>>>> Now from what I see Postfix looks for a match when rewriting addresses
>>>>> in the following order:
>>>>> 
>>>>> Look for a match of:
>>>>>   - user@domain in the first table
>>>>>   - user@domain in the second table
>>>>>   - user in the first table
>>>>>   - user in the second table
>>>>>   - @domain in the first table
>>>>>   - @domain in the second table
>>>>> 
>>>>> Is there a way to make Postfix do the lookup in the following order 
>>>>> instead?
>>>>> 
>>>>> Look for a match of:
>>>>>   - user@domain in the first table
>>>>>   - user in the first table
>>>>>   - @domain in the first table
>>>>>   - user@domain in the second table
>>>>>   - user in the second table
>>>>>   - @domain in the second table
>>>> 
>>>> That is not implemented. The code that generates partial queries
>>>> is separate from the code that searches lookup tables (the same
>>>> comes up with partial access(5) queries, or even header/body checks.
>>>> Asking for this to be changed will not automatically make it happen.
>>>> 
>>>> In the case of LDAP/SQL queries, you can enable the domain filter
>>>> to avoid the domain-less queries.
>>>> 
>>>>Wietse
>>>> 
>>> 



Re: Processing order of canonical maps

2016-09-16 Thread Ondřej Lysoněk
It just doesn't seem very clear to me. And one of our customers even got 
the wrong impression about the search order. I think a sentence like the 
following could be dropped in there somewhere: "First, a match of 
'user@domain' is searched for across all the listed tables in the order 
the tables are listed. If no match is found, a match of 'user' is 
searched for in all the listed tables, and so on". Or something less 
horrible.


Ondra

On 09/16/2016 12:51 PM, Wietse Venema wrote:

canonical(5) section "TABLE SEARCH ORDER":

"With lookups from indexed files such as DB or DBM,  or  from
networked tables  such  as  NIS,  LDAP or SQL, patterns are tried
in the order as listed below:"

That really does what it says: try the first query.  Try the second
query. And so on.

postconf(5) section "canonical_maps":

"Tables will be searched in the specified order until a match
 is found.  Note: these lookups are recursive."

That really works as described. For each query, search the first
table. Try the second table. And so on.

The information is in two places, but it is not ambiguous.

Are you proposing to mix these descriptions?

Wietse

Ond?ej Lyson?k:
[ Charset windows-1252 converted... ]

Thank you!

The documentation seems a bit ambiguous on this topic. After reading
canonical(5) and the canonical_maps section of postconf(5), I think it's
not clear which of the processing orders, mentioned in the first email,
it actually uses. Would you like me to write a patch for this?

Ondra


On 09/15/2016 03:46 PM, Wietse Venema wrote:

Ond?ej Lyson?k:

Hi,

I need some help configuring canonical maps.

Suppose you have two lookup tables listed in canonical_maps and each of
these tables uses all three pattern types (user@domain, user, @domain).
Now from what I see Postfix looks for a match when rewriting addresses
in the following order:

Look for a match of:
   - user@domain in the first table
   - user@domain in the second table
   - user in the first table
   - user in the second table
   - @domain in the first table
   - @domain in the second table

Is there a way to make Postfix do the lookup in the following order instead?

Look for a match of:
   - user@domain in the first table
   - user in the first table
   - @domain in the first table
   - user@domain in the second table
   - user in the second table
   - @domain in the second table


That is not implemented. The code that generates partial queries
is separate from the code that searches lookup tables (the same
comes up with partial access(5) queries, or even header/body checks.
Asking for this to be changed will not automatically make it happen.

In the case of LDAP/SQL queries, you can enable the domain filter
to avoid the domain-less queries.

Wietse





Re: Processing order of canonical maps

2016-09-16 Thread Wietse Venema
canonical(5) section "TABLE SEARCH ORDER":

"With lookups from indexed files such as DB or DBM,  or  from
networked tables  such  as  NIS,  LDAP or SQL, patterns are tried
in the order as listed below:"

That really does what it says: try the first query.  Try the second
query. And so on.

postconf(5) section "canonical_maps":

"Tables will be searched in the specified order until a match
 is found.  Note: these lookups are recursive."

That really works as described. For each query, search the first
table. Try the second table. And so on.

The information is in two places, but it is not ambiguous.

Are you proposing to mix these descriptions?

Wietse

Ond?ej Lyson?k:
[ Charset windows-1252 converted... ]
> Thank you!
> 
> The documentation seems a bit ambiguous on this topic. After reading 
> canonical(5) and the canonical_maps section of postconf(5), I think it's 
> not clear which of the processing orders, mentioned in the first email, 
> it actually uses. Would you like me to write a patch for this?
> 
> Ondra
> 
> 
> On 09/15/2016 03:46 PM, Wietse Venema wrote:
> > Ond?ej Lyson?k:
> >> Hi,
> >>
> >> I need some help configuring canonical maps.
> >>
> >> Suppose you have two lookup tables listed in canonical_maps and each of
> >> these tables uses all three pattern types (user@domain, user, @domain).
> >> Now from what I see Postfix looks for a match when rewriting addresses
> >> in the following order:
> >>
> >> Look for a match of:
> >>- user@domain in the first table
> >>- user@domain in the second table
> >>- user in the first table
> >>- user in the second table
> >>- @domain in the first table
> >>- @domain in the second table
> >>
> >> Is there a way to make Postfix do the lookup in the following order 
> >> instead?
> >>
> >> Look for a match of:
> >>- user@domain in the first table
> >>- user in the first table
> >>- @domain in the first table
> >>- user@domain in the second table
> >>- user in the second table
> >>- @domain in the second table
> >
> > That is not implemented. The code that generates partial queries
> > is separate from the code that searches lookup tables (the same
> > comes up with partial access(5) queries, or even header/body checks.
> > Asking for this to be changed will not automatically make it happen.
> >
> > In the case of LDAP/SQL queries, you can enable the domain filter
> > to avoid the domain-less queries.
> >
> > Wietse
> >
> 


Re: Processing order of canonical maps

2016-09-16 Thread Ondřej Lysoněk

Thank you!

The documentation seems a bit ambiguous on this topic. After reading 
canonical(5) and the canonical_maps section of postconf(5), I think it's 
not clear which of the processing orders, mentioned in the first email, 
it actually uses. Would you like me to write a patch for this?


Ondra


On 09/15/2016 03:46 PM, Wietse Venema wrote:

Ond?ej Lyson?k:

Hi,

I need some help configuring canonical maps.

Suppose you have two lookup tables listed in canonical_maps and each of
these tables uses all three pattern types (user@domain, user, @domain).
Now from what I see Postfix looks for a match when rewriting addresses
in the following order:

Look for a match of:
   - user@domain in the first table
   - user@domain in the second table
   - user in the first table
   - user in the second table
   - @domain in the first table
   - @domain in the second table

Is there a way to make Postfix do the lookup in the following order instead?

Look for a match of:
   - user@domain in the first table
   - user in the first table
   - @domain in the first table
   - user@domain in the second table
   - user in the second table
   - @domain in the second table


That is not implemented. The code that generates partial queries
is separate from the code that searches lookup tables (the same
comes up with partial access(5) queries, or even header/body checks.
Asking for this to be changed will not automatically make it happen.

In the case of LDAP/SQL queries, you can enable the domain filter
to avoid the domain-less queries.

Wietse



Re: Processing order of canonical maps

2016-09-15 Thread Wietse Venema
Ond?ej Lyson?k:
> Hi,
> 
> I need some help configuring canonical maps.
> 
> Suppose you have two lookup tables listed in canonical_maps and each of 
> these tables uses all three pattern types (user@domain, user, @domain). 
> Now from what I see Postfix looks for a match when rewriting addresses 
> in the following order:
> 
> Look for a match of:
>- user@domain in the first table
>- user@domain in the second table
>- user in the first table
>- user in the second table
>- @domain in the first table
>- @domain in the second table
> 
> Is there a way to make Postfix do the lookup in the following order instead?
> 
> Look for a match of:
>- user@domain in the first table
>- user in the first table
>- @domain in the first table
>- user@domain in the second table
>- user in the second table
>- @domain in the second table

That is not implemented. The code that generates partial queries
is separate from the code that searches lookup tables (the same
comes up with partial access(5) queries, or even header/body checks.
Asking for this to be changed will not automatically make it happen.

In the case of LDAP/SQL queries, you can enable the domain filter
to avoid the domain-less queries.

Wietse


Processing order of canonical maps

2016-09-15 Thread Ondřej Lysoněk

Hi,

I need some help configuring canonical maps.

Suppose you have two lookup tables listed in canonical_maps and each of 
these tables uses all three pattern types (user@domain, user, @domain). 
Now from what I see Postfix looks for a match when rewriting addresses 
in the following order:


Look for a match of:
  - user@domain in the first table
  - user@domain in the second table
  - user in the first table
  - user in the second table
  - @domain in the first table
  - @domain in the second table

Is there a way to make Postfix do the lookup in the following order instead?

Look for a match of:
  - user@domain in the first table
  - user in the first table
  - @domain in the first table
  - user@domain in the second table
  - user in the second table
  - @domain in the second table

Thanks.

Ondra


Re: rewriting from and reply-to headers: milter vs canonical maps/header checks

2014-08-21 Thread Wietse Venema
Venkat:
 What I am trying to do is:
 
 Setup a SMTP relay for outgoing mail where:
 (a) All From: headers of the form u...@cooldomain1.com (example) are
 rewritten to be no-re...@cooldomain2.com
 (b) A Reply-To: header with the original u...@cooldomain1.com is added
 
 I have achieved this by using this combination:
 -- using sender_canonical_maps set to:
 @cooldomain1.com  no-re...@cooldomain2.com
 -- using header_checks set to:
 /^From: (.*@cooldomain1\.com)/ PREPEND Reply-To:$1
 
 This seems to work. However, I am not sure if this is a good
 approach or would using a milter (FILTER action in header_checks)
 be a better way? If so, is there a pre-existing milter available
 for this that is recommended? Thanks all.

Your configuration should be safe, if I read Postfix documentation
carefully. Remember, undocumented Postfix behavior is not covered
by any promise of future compatibility.

The header_checks manpage promises that PREPENDed text is not subject
to header_checks or address rewriting, and that it does not affect
the way that Postfix adds missing message headers.  So this part
of your design is safe.

Does Postfix documentation promise that header_checks happen before
address rewriting? It makes that promise in a non-obvious manner.

The text for the REPLACE action says that the replacement text
will be subject to address rewriting (among other things). This
suggests that header_checks happen before address rewriting.

So there is an implicit promise that header_checks happen before
address rewriting. This order should probably be documented, along
with the relative timing of Milter activity.

Wietse


Re: rewriting from and reply-to headers: milter vs canonical maps/header checks

2014-08-21 Thread Venkat
Thank you very much for the detailed explanation Wietse, it makes more
sense to me now re: the order of operations.

Cheers,

VM
On Aug 21, 2014 5:31 AM, Wietse Venema wie...@porcupine.org wrote:

 Venkat:
  What I am trying to do is:
 
  Setup a SMTP relay for outgoing mail where:
  (a) All From: headers of the form u...@cooldomain1.com (example) are
  rewritten to be no-re...@cooldomain2.com
  (b) A Reply-To: header with the original u...@cooldomain1.com is added
 
  I have achieved this by using this combination:
  -- using sender_canonical_maps set to:
  @cooldomain1.com  no-re...@cooldomain2.com
  -- using header_checks set to:
  /^From: (.*@cooldomain1\.com)/ PREPEND Reply-To:$1
 
  This seems to work. However, I am not sure if this is a good
  approach or would using a milter (FILTER action in header_checks)
  be a better way? If so, is there a pre-existing milter available
  for this that is recommended? Thanks all.

 Your configuration should be safe, if I read Postfix documentation
 carefully. Remember, undocumented Postfix behavior is not covered
 by any promise of future compatibility.

 The header_checks manpage promises that PREPENDed text is not subject
 to header_checks or address rewriting, and that it does not affect
 the way that Postfix adds missing message headers.  So this part
 of your design is safe.

 Does Postfix documentation promise that header_checks happen before
 address rewriting? It makes that promise in a non-obvious manner.

 The text for the REPLACE action says that the replacement text
 will be subject to address rewriting (among other things). This
 suggests that header_checks happen before address rewriting.

 So there is an implicit promise that header_checks happen before
 address rewriting. This order should probably be documented, along
 with the relative timing of Milter activity.

 Wietse



rewriting from and reply-to headers: milter vs canonical maps/header checks

2014-08-20 Thread Venkat
Hi all,

Apologies in advance if this is a redundant query. I did some searching on
the previous list posts and wasn't able to find a definitive recommendation
on this.

What I am trying to do is:

Setup a SMTP relay for outgoing mail where:
(a) All From: headers of the form u...@cooldomain1.com (example) are
rewritten to be no-re...@cooldomain2.com
(b) A Reply-To: header with the original u...@cooldomain1.com is added

I have achieved this by using this combination:
-- using sender_canonical_maps set to:
@cooldomain1.com  no-re...@cooldomain2.com
-- using header_checks set to:
/^From: (.*@cooldomain1\.com)/ PREPEND Reply-To:$1

This seems to work. However, I am not sure if this is a good approach or
would using a
milter (FILTER action in header_checks) be a better way? If so, is there a
pre-existing milter
available for this that is recommended? Thanks all.

cheers,

VM


Need help with canonical maps

2014-08-17 Thread Michael Fox
I'm having difficulty getting the canonical_maps function to work as needed
to repair some incorrect addresses from a legacy client.  Here's the
situation and what I've tried so far:

Legacy client (oldhost.legacy.org) does not append its domain (legacy.org)
to addresses in the envelope or the message when sending them via SMTP.  So,
if the user on oldhost types an address such as user@oldhost, it goes out
with SMTP as user@oldhost instead of u...@oldhost.legacy.org.

A machine with postfix (newhost.standard.org) has a different domain
(standard.org) from the legacy machine.  It acts as MX and relay for the
oldhost.legacy.org domain.  Relaying in both directions works fine.  Only
the address rewriting function which I'm trying to add is not working
properly.

When messages from the legacy client arrive at the postfix machine with
addresses such as user@oldhost (missing .legacy.org), I'd like to rewrite
those to read u...@oldhost.legacy.org.  It's my understanding that the
canonical_maps function is intended for this purpose.

In /etc/postfix/canonical.pcre I have:
/^(.*@oldhost)$/$1.legacy.org

If I test with:  postmap -q user@oldhost pcre:/etc/postfix/canonical.pcre
the answer is:  u...@oldhost.legacy.org.  Perfect.

In /etc/postfix/main.cf I have
canonical_maps = pcre:/etc/postfix/canonical.pcre

Then, on the legacy host, I send a message such as:
To:  user@someotherhost.domain
Cc:  user@oldhost

The message arrives at the postfix machine, but the CC line is not
rewritten.

The documentation for canonical_maps says that in order for the headers to
be rewritten, the client needs to either match the
local_header_rewrite_clients or else the remote_header_rewrite_domain must
be non-null.  I tried both but neither produces the output that I need.
Here's what I found:

If I set local_header_rewrite_clients = static:all or permit_mynetworks or
some other option that would cause a match of the legacy client, then the
append_dot_domain option takes over and appends the domain of the postfix
host, rewriting the address as u...@oldhost.standard.org.  The canonical
table is apparently ignored.

If I instead leave local_header_rewrite_clients at its default (which does
not match the legacy client) and turn on remote_header_rewrite_domain =
invalid.domain, then the address is rewritten as user@oldhost.invalid.domain
and, once again, the canonical table is apparently ignored.

So the documentation for the canonical table is correct, in that rewriting
only occurs if the local_header_rewrite_clients matches the client or if
remote_header_rewrite_domain is set.  And the rewrites are indeed occurring.
But the rewriting that takes place completely ignores the canonical table.
This seems like a catch-22 situation.

I don't want to turn off append_dot_domain or append_at_myorigin because I
need that for the local linux machine where postfix is running.  If the
canonical table rewrites were applied first, then the append_... functions
would not apply.  So how do I get postfix to apply the canonical table first
(or at all)?

Michael





Re: Need help with canonical maps

2014-08-17 Thread Wietse Venema
Michael Fox:
 If I set local_header_rewrite_clients = static:all or permit_mynetworks or
 some other option that would cause a match of the legacy client, then the
 append_dot_domain option takes over and appends the domain of the postfix
 host, rewriting the address as u...@oldhost.standard.org.  The canonical
 table is apparently ignored.

As documented in ADDRESS_REWRITING_README, canonical mapping happens
after append_dot_mydomain.

Thus, either turn off append_dot_mydomain (which may also change
the handling of other email addresses, which may break something),
or change canonical_maps to rewrite the address that results from
append_dot_mydomain, i.e.  u...@oldhost.standard.org

Wietse


RE: Need help with canonical maps

2014-08-17 Thread Michael Fox
Thanks much, Wietse.

A couple of follow-ups:

 As documented in ADDRESS_REWRITING_README, canonical mapping happens
 after append_dot_mydomain.

O.K.  I read that document but did not see that statement.  I just went back
and read it again and I still don't see that.  Perhaps the order of
processing can be more explicitly stated?

 Thus, either turn off append_dot_mydomain (which may also change
 the handling of other email addresses, which may break something),
 or change canonical_maps to rewrite the address that results from
 append_dot_mydomain, i.e.  u...@oldhost.standard.org

I presume there is a reason for the current processing order.  But it seems
it causes the need to rewrite a rewrite.  In other words, as you described,
I either have to turn off a feature (append_dot_mydomain) and then fix the
problem that that creates in canonical_maps, or else use canonical to
rewrite an address that has already been rewritten.  

The reverse order seems more intuitive and useful (at least to me).  If
canonical was processed first, one would have the opportunity to fix the
error as it is coming in, before it is further manipulated and, perhaps,
becomes harder to distinguish from other addresses.  Then, anything left
over could be handled by append_dot_mydomain or the
remote_header_rewrite_domain, wherever they apply.  

For backward compatibility, perhaps a switch could be provided to control
the order.  Just a thought.  

Once again, thanks for the quick reply.

Michael




Re: Need help with canonical maps

2014-08-17 Thread Wietse Venema
Michael Fox:
 Thanks much, Wietse.
 
 A couple of follow-ups:
 
  As documented in ADDRESS_REWRITING_README, canonical mapping happens
  after append_dot_mydomain.
 
 O.K.  I read that document but did not see that statement.  I just went back
 and read it again and I still don't see that.  Perhaps the order of
 processing can be more explicitly stated?

Hmm. ADDRESS_REWRITING_README describes the address manipulations
in the order as executed. Presenting these descriptions in a different
order would be misleading.

 For backward compatibility, perhaps a switch could be provided to control
 the order.  Just a thought.  

That would require not a switch, but a mechanism to specify the
order of all five cleanup server's address manipulations.

Wietse


RE: Need help with canonical maps

2014-08-17 Thread Michael Fox
Thanks again Wietse.

 Hmm. ADDRESS_REWRITING_README describes the address manipulations
 in the order as executed. Presenting these descriptions in a different
 order would be misleading.

Yes.  And it's very well written.  But assuming or inferring information
that is not in a technical document is usually not a wise move.  Currently,
the processing order is implied by the order mentioned in the document.  But
I didn't want to assume that.  I would respectfully suggest an explicit
statement in the document so the reader doesn't need to infer the processing
order.


 That would require not a switch, but a mechanism to specify the
 order of all five cleanup server's address manipulations.

Yes, good point.  Perhaps that's too complex to address what may be a
shrinking problem today (cleaning up legacy client addresses).

Best regards, and thanks again for the quick help!

Michael



Re: canonical maps

2014-01-09 Thread Charles Marcus

On 2014-01-08 3:18 PM, R. Berger dove...@w4r.nl wrote:
In sendmail, when I use @domain.nl %1...@otherdomain.nl domain.nl 
wil automatically have 29 users also.
If there is a mail send to n...@domain.nl and n...@otherdomain.nl does 
not exist, it will be rejected.
In postfixadmin this will be a domain alias but that isn't working 
with local virtual users. 


So you just want domain aliasing (which does not break recipient 
validation)?


This can be done with properly constructed SQL...

And your OP said you are using postfixadmin? If you are indeed using it, 
then you can do this very easily in postfixadmin by simply using the 
alias domain feature.


--

Best regards,

Charles




canonical maps

2014-01-08 Thread R. Berger

hi,

I have the following problem coming from sendmail:
This is how it is set up in virtusertable:
@domain.nl   %1...@otherdomain.nl
us...@domain.nl  localuser1
us...@domain.nl   localuser2
us...@domain.nl localuser3

I am using postfixadmin and the local users are working.
But how do I forward all the other mail? I understand I can do that for 
a complete domain using canonical_maps option but does it work together 
with local virtual users?


Thanks,
Roger




Re: canonical maps

2014-01-08 Thread Wietse Venema
R. Berger:
 hi,
 
 I have the following problem coming from sendmail:
 This is how it is set up in virtusertable:
 @domain.nl   %1...@otherdomain.nl
 us...@domain.nl  localuser1
 us...@domain.nl   localuser2
 us...@domain.nl localuser3

If you can explain what the above means for Sendmail, then someone
can try to show how to do the same in Postfix.

I suspect that you want to use Postfix virtual_alias_maps instead
of canonical_maps.

If the equivalent is this (in terms of hash: files):

/etc/postfix/main.cf:
virtual_alias_maps = hash:/etc/postfix/virtual ...

/etc/postfix/virtual
us...@domain.nl localus...@example.com
us...@domain.nl localus...@example.com
us...@domain.nl localus...@example.com
@domain.nl  @otherdomain.nl

Then you are accepting mail with non-existent recipient addresses
and forwarding it to otherdomain.nl. That is bad. Such mail will
bounce and you become a backscatter source.

Instead, use this:

/etc/postfix/main.cf: 
virtual_alias_maps = hash:/etc/postfix/virtual ...
virtual_alias_domains = otherdomain.nl ...

/etc/postfix/virtual 
us...@domain.nl localus...@example.com
us...@domain.nl localus...@example.com
us...@domain.nl localus...@example.com

That will reject mail for users that you haven't defined.

Wietse

 I am using postfixadmin and the local users are working.
 But how do I forward all the other mail? I understand I can do that for 
 a complete domain using canonical_maps option but does it work together 
 with local virtual users?
 
 Thanks,
 Roger
 
 
 


Re: canonical maps

2014-01-08 Thread R. Berger


Wietse Venema schreef op 8-1-2014 20:20:

R. Berger:

hi,

I have the following problem coming from sendmail:
This is how it is set up in virtusertable:
@domain.nl   %1...@otherdomain.nl
us...@domain.nl  localuser1
us...@domain.nl   localuser2
us...@domain.nl localuser3

If you can explain what the above means for Sendmail, then someone
can try to show how to do the same in Postfix.

I suspect that you want to use Postfix virtual_alias_maps instead
of canonical_maps.

If the equivalent is this (in terms of hash: files):

/etc/postfix/main.cf:
 virtual_alias_maps = hash:/etc/postfix/virtual ...

/etc/postfix/virtual
 us...@domain.nllocalus...@example.com
 us...@domain.nllocalus...@example.com
 us...@domain.nllocalus...@example.com
 @domain.nl @otherdomain.nl

Then you are accepting mail with non-existent recipient addresses
and forwarding it to otherdomain.nl. That is bad. Such mail will
bounce and you become a backscatter source.

Instead, use this:

/etc/postfix/main.cf:
 virtual_alias_maps = hash:/etc/postfix/virtual ...
 virtual_alias_domains = otherdomain.nl ...

/etc/postfix/virtual
 us...@domain.nl localus...@example.com
 us...@domain.nl localus...@example.com
 us...@domain.nl localus...@example.com

That will reject mail for users that you haven't defined.

Wietse

It's not exactly a catchall.
@domain.nl%1...@otherdomain.nl
means that somen...@domain.nl is send to somen...@otherdomain.nl
So if there is no catchall for otherdomain.nl there is no catchall for 
domain.nl

both domains are local btw.
So basically you have 3 local users which are directly connected to 
domain.nl and the rest has to be forwarded to another domain if the 
username in front of the @ exists.



I am using postfixadmin and the local users are working.
But how do I forward all the other mail? I understand I can do that for
a complete domain using canonical_maps option but does it work together
with local virtual users?

Thanks,
Roger








Re: canonical maps

2014-01-08 Thread Wietse Venema
R. Berger:
 It's not exactly a catchall.
 @domain.nl%1...@otherdomain.nl
 means that somen...@domain.nl is send to somen...@otherdomain.nl

I wrote that you will accept mail for non-existent recipients in
otherdomain.nl.

That is bad.

Your system will be sending backscatter mail to innocent people.

Wietse



Re: canonical maps

2014-01-08 Thread R. Berger


Wietse Venema schreef op 8-1-2014 20:47:

R. Berger:

It's not exactly a catchall.
@domain.nl%1...@otherdomain.nl
means that somen...@domain.nl is send to somen...@otherdomain.nl

I wrote that you will accept mail for non-existent recipients in
otherdomain.nl.

That is bad.

Your system will be sending backscatter mail to innocent people.

Wietse


Why is that? Otherdomain has 29 users
In sendmail, when I use @domain.nl %1...@otherdomain.nl domain.nl wil 
automatically have 29 users also.
If there is a mail send to n...@domain.nl and n...@otherdomain.nl does 
not exist, it will be rejected.
In postfixadmin this will be a domain alias but that isn't working with 
local virtual users.


Roger



Re: canonical maps

2014-01-08 Thread Wietse Venema
R. Berger:
  R. Berger:
  It's not exactly a catchall.
  @domain.nl%1...@otherdomain.nl
  means that somen...@domain.nl is send to somen...@otherdomain.nl
  I wrote that you will accept mail for non-existent recipients in
  otherdomain.nl.
  That is bad.
  Your system will be sending backscatter mail to innocent people.

 Why is that?

Because you never explained what the Sendmail configuration does.

With Postfix you will have to enumerate all 29 recipients.

Wietse


Re: canonical maps

2014-01-08 Thread R. Berger


Wietse Venema schreef op 8-1-2014 21:46:

R. Berger:

R. Berger:

It's not exactly a catchall.
@domain.nl%1...@otherdomain.nl
means that somen...@domain.nl is send to somen...@otherdomain.nl

I wrote that you will accept mail for non-existent recipients in
otherdomain.nl.
That is bad.
Your system will be sending backscatter mail to innocent people.

Why is that?

Because you never explained what the Sendmail configuration does.

With Postfix you will have to enumerate all 29 recipients.

Wietse

OK, sorry about that.
Anyway thanks a lot and thanks for the excellent software!