Re: unexpected delivery location

2017-08-29 Thread lists

For the archives:

On 23-8-2017 21:56, Noel wrote:

Perhaps you can adjust your query or your database to return the
desired result.  Otherwise, use your scripting skills to generate a
file, then automate the procedure.


I ended up creating a file /etc/postfix/olddomain with this contents:


/^([^@]*)@olddomain.com/ $(1)@newdomain.com


and reference that in main.cf like:

virtual_alias_maps = regexp:/etc/postfix/olddomain

That seems to to the job nicely:

Emails for exist...@olddomain.com are delivered to 
exist...@newdomain.com, and mails sent to nonexist...@olddomain.com 
receive DSN Undelivered Mail Returned to Sender, with:


 (expanded from ): 
user unknown


Perfect. :-)


Re: unexpected delivery location

2017-08-23 Thread mj

Hi,

On 08/23/2017 09:56 PM, Noel wrote:

Perhaps you can adjust your query or your database to return the
desired result.  Otherwise, use your scripting skills to generate a
file, then automate the procedure.


Thanks for the suggestion, I try something like that.

Still feel that some simple config to make one domain an alias to 
another domain would be very useful. :-)


MJ


Re: unexpected delivery location

2017-08-23 Thread Noel
On 8/23/2017 2:53 PM, mj wrote:
>
> On 08/23/2017 06:03 PM, Noel wrote:
>> Don't use wildcard aliases.  They break recipient validation and
>> cause postfix to accept all addresses.
>>
>> Instead use 1-1 aliases, such as
>> user1@olddomaon  user1@newdomain
>> user2@olddomaon  user2@newdomain
>
> But we have 500+ addresses in ldap, surely there must be some
> 'automated' way to 'transform' any incoming mail sent to
> ran...@olddomain.com into ran...@newdomain.com?
>
> (and then have it processed regularly, so that bounces still work
> for non-existant addresses and such)
>
> MJ


Perhaps you can adjust your query or your database to return the
desired result.  Otherwise, use your scripting skills to generate a
file, then automate the procedure.



  -- Noel Jones


Re: unexpected delivery location

2017-08-23 Thread mj

Hi Noël,

Thanks for your response!

On 08/23/2017 06:03 PM, Noel wrote:

Don't use wildcard aliases.  They break recipient validation and
cause postfix to accept all addresses.

Instead use 1-1 aliases, such as
user1@olddomaon  user1@newdomain
user2@olddomaon  user2@newdomain


But we have 500+ addresses in ldap, surely there must be some 
'automated' way to 'transform' any incoming mail sent to 
ran...@olddomain.com into ran...@newdomain.com?


(and then have it processed regularly, so that bounces still work for 
non-existant addresses and such)


MJ


Re: unexpected delivery location

2017-08-23 Thread Noel
On 8/23/2017 4:30 AM, lists wrote:
> Hi,
>
> Not sure what the lack of replies means... As postfix is also
> involved, should I better ask there?
>
> It seems a little bit in between postfix and dovecot...
>
> Just to clearify one thing I wrote:
>
> On 22-8-2017 16:23, lists wrote:
>> We're running dovecot 2.2.13, virtual users, with postfix. We
>> have an olddomain and a new domainname. To 'translate'
>> *@olddomain into 
>
> With "translate" I mean that olddomain should be treated as if it
> were newdomain. No translation, but more like an alias.
>
> MJ


Don't use wildcard aliases.  They break recipient validation and
cause postfix to accept all addresses.

Instead use 1-1 aliases, such as
user1@olddomaon  user1@newdomain
user2@olddomaon  user2@newdomain
user3@olddomaon  user3@newdomain
...



  -- Noel Jones


Re: unexpected delivery location

2017-08-23 Thread lists

Hi,

Not sure what the lack of replies means... As postfix is also involved, 
should I better ask there?


It seems a little bit in between postfix and dovecot...

Just to clearify one thing I wrote:

On 22-8-2017 16:23, lists wrote:
We're running dovecot 2.2.13, virtual users, with postfix. We have an 
olddomain and a new domainname. To 'translate' *@olddomain into 


With "translate" I mean that olddomain should be treated as if it were 
newdomain. No translation, but more like an alias.


MJ


unexpected delivery location

2017-08-22 Thread lists

Hi,

We're running dovecot 2.2.13, virtual users, with postfix. We have an 
olddomain and a new domainname. To 'translate' *@olddomain into 
*@newdomain, I have configured:



cat /etc/postfix/canonical
@olddomain.com   @newdomain.com


While this seems to work, lately we have noticed that dovecot 
occasionally creates mailboxes for non-existent users, like:

/var/vmail/...username
/var/vmail/20username


This only seems to be happening for mails sent to *olddomain*

Looking at the source of these mails, they are indeed sent to 
20usern...@olddomain.com and ...usern...@olddomain.com


Mail headers sample:

Delivered-To: 20usern...@newdomain.com
Received: from server1.newdomain.com (server2.newdomain.com [x.y.z.q])
by server3.newdomain.com (Postfix) with ESMTPS id 067B4812CF29E
for <20usern...@olddomain.com>; Thu, 13 Jul 2017 19:05:02 +0200 (CEST)


Why doesn't the emailadress 20usern...@newdomain.com in the above 
generate an error, but instead are delivered to a newly created mailbox?


My feeling is that something is wrong with the way I created the alias 
for olddomain -> newdomain with the canonical-file . Does that make sense?


Our goal is to accept *@olddomain.com like it was sent to 
*@newdomain.com, including delivery failures for nonexistent mailboxes 
like 20username


We configured postfix like:

canonical_maps = hash:/etc/postfix/canonical
virtual_alias_maps = ldap:/etc/postfix/ad-mailboxes.cf, 
ldap:/etc/postfix/ad-groups.cf
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
virtual_transport = dovecot


Verified that this config works for newdomain, using:

root@mail:/etc/postfix# postmap -q al...@newdomain.com  
ldap:/etc/postfix/ad-mailboxes.cf
use...@newdomain.com
root@mail:/etc/postfix# postmap -q al...@olddomain.com  
ldap:/etc/postfix/ad-mailboxes.cf
root@mail:/etc/postfix# 

olddomain gives no result.

Then, from master.cf:

dovecot unix - n n - - pipe
  flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -f ${sender} -a 
${recipient} -d ${user}@${nexthop}


Finally, the mail location as defined in dovecot:


mail_location = maildir:/var/vmail/%Ln/Maildir:LAYOUT=fs:DIRNAME=mAildir


So, can anyone explain why for mails to olddomain, dovecot creates new 
mailboxes, instead of simply generating an error?