propagate_unmatched_extensions broken with virtual aliases in postfix 3.2?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

propagate_unmatched_extensions broken with virtual aliases in postfix 3.2?

Raimar Sandner
Hi,

there seems to be a regression after upgrading from postfix 3.1.4 to 3.2.2 on arch linux. I'm using virtual aliases with

recipient_delimiter = .
propagate_unmatched_extensions = canonical, virtual

For a given virtual mapping

   [hidden email] => [hidden email]

postfix 3.1 will map  [hidden email] to [hidden email]. This is working perfectly fine: When I receive a mail on [hidden email], postfix 3.1 logs

------ snip -------
postfix/lmtp[16546]: 4FCAF44764: to=<[hidden email]>, orig_to=<[hidden email]>, relay=<hostname removed>[private/dovecot-lmtp], delay=1.2, delays=0.1/0.01/0.01/1.1, dsn=2.0.0, status=sent (250 2.0.0 <[hidden email]> Jw8BGpV3SVmjQAAAT7qhFg Saved)
------ snip -------

This setup stopped working with postfix 3.2 with the exact same configuration. The extension is not propagated anymore, postfix 3.2 logs

------ snip -------
postfix/lmtp[17650]: B4E614030E: to=<[hidden email]>, orig_to=<[hidden email]>, relay=<hostname removed>[private/dovecot-lmtp], delay=0.89, delays=0.07/0.01/0.01/0.8, dsn=2.0.0, status=sent (250 2.0.0 <[hidden email]> bsYAMch/SVnzRAAAT7qhFg Saved)
------ snip -------

How can I restore the behaviour of postfix 3.1? Your help is greatly appreciated! I'm glad to provide more information in case I forgot something relevant.

Cheers
Raimar

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: propagate_unmatched_extensions broken with virtual aliases in postfix 3.2?

Wietse Venema
Raimar Sandner:

> Hi,
>
> there seems to be a regression after upgrading from postfix 3.1.4 to 3.2.2 on arch linux. I'm using virtual aliases with
>
> recipient_delimiter = .
> propagate_unmatched_extensions = canonical, virtual
>
> For a given virtual mapping
>
>    [hidden email] => [hidden email]
>
> postfix 3.1 will map  [hidden email] to [hidden email]. This is working perfectly fine: When I receive a mail on [hidden email], postfix 3.1 logs
>
> ------ snip -------
> postfix/lmtp[16546]: 4FCAF44764: to=<[hidden email]>, orig_to=<[hidden email]>, relay=<hostname removed>[private/dovecot-lmtp], delay=1.2, delays=0.1/0.01/0.01/1.1, dsn=2.0.0, status=sent (250 2.0.0 <[hidden email]> Jw8BGpV3SVmjQAAAT7qhFg Saved)
> ------ snip -------
>
> This setup stopped working with postfix 3.2 with the exact same configuration. The extension is not propagated anymore, postfix 3.2 logs
>
> ------ snip -------
> postfix/lmtp[17650]: B4E614030E: to=<[hidden email]>, orig_to=<[hidden email]>, relay=<hostname removed>[private/dovecot-lmtp], delay=0.89, delays=0.07/0.01/0.01/0.8, dsn=2.0.0, status=sent (250 2.0.0 <[hidden email]> bsYAMch/SVnzRAAAT7qhFg Saved)
> ------ snip -------
>
> How can I restore the behaviour of postfix 3.1? Your help is greatly appreciated! I'm glad to provide more information in case I forgot something relevant.
>

That will require a bugfix. After many years, the address mapping
code needed to be cleaned up, and I thought that all the tests would
have caught any incompatibilities, but apparently not.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: propagate_unmatched_extensions broken with virtual aliases in postfix 3.2?

Raimar Sandner
On Dienstag, 20. Juni 2017 22:33:34 CEST Wietse Venema wrote:

> Raimar Sandner:
> > Hi,
> >
> > there seems to be a regression after upgrading from postfix 3.1.4 to 3.2.2
> > on arch linux. I'm using virtual aliases with
> >  ...
> > postfix 3.1 will map  [hidden email] to [hidden email]. This
> > is working perfectly fine: When I receive a mail on
> > [hidden email], postfix 3.1 logs
> >  ...
> > This setup stopped working with postfix 3.2 with the exact same
> > configuration. The extension is not propagated anymore, postfix 3.2 logs
> > ...
> > How can I restore the behaviour of postfix 3.1? Your help is greatly
> > appreciated! I'm glad to provide more information in case I forgot
> > something relevant.
> That will require a bugfix. After many years, the address mapping
> code needed to be cleaned up, and I thought that all the tests would
> have caught any incompatibilities, but apparently not.
>
> Wietse

Thanks for the quick reply! I think I will stick with 3.1 for the time being.
Can I help by reporting the bug somewhere besides here?

Cheers
Raimar
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: propagate_unmatched_extensions broken with virtual aliases in postfix 3.2?

Noel Jones-2
On 6/20/2017 3:56 PM, Raimar Sandner wrote:
> On Dienstag, 20. Juni 2017 22:33:34 CEST Wietse Venema wrote:
...

>> That will require a bugfix. After many years, the address mapping
>> code needed to be cleaned up, and I thought that all the tests would
>> have caught any incompatibilities, but apparently not.
>>
>> Wietse
>
> Thanks for the quick reply! I think I will stick with 3.1 for the time being.
> Can I help by reporting the bug somewhere besides here?
>
> Cheers
> Raimar
>


This is the only bug report necessary.

Thanks for bringing this to our attention.



  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: propagate_unmatched_extensions broken with virtual aliases in postfix 3.2?

Wietse Venema
In reply to this post by Raimar Sandner
Raimar Sandner:

> On Dienstag, 20. Juni 2017 22:33:34 CEST Wietse Venema wrote:
> > Raimar Sandner:
> > > Hi,
> > >
> > > there seems to be a regression after upgrading from postfix 3.1.4 to 3.2.2
> > > on arch linux. I'm using virtual aliases with
> > >  ...
> > > postfix 3.1 will map  [hidden email] to [hidden email]. This
> > > is working perfectly fine: When I receive a mail on
> > > [hidden email], postfix 3.1 logs
> > >  ...
> > > This setup stopped working with postfix 3.2 with the exact same
> > > configuration. The extension is not propagated anymore, postfix 3.2 logs
> > > ...
> > > How can I restore the behaviour of postfix 3.1? Your help is greatly
> > > appreciated! I'm glad to provide more information in case I forgot
> > > something relevant.
> > That will require a bugfix. After many years, the address mapping
> > code needed to be cleaned up, and I thought that all the tests would
> > have caught any incompatibilities, but apparently not.
> >
> > Wietse
>
> Thanks for the quick reply! I think I will stick with 3.1 for the time being.
> Can I help by reporting the bug somewhere besides here?

I already located the problem. We don't have a huge list of bugs.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

PATCH: propagate_unmatched_extensions broken with virtual aliases in postfix 3.2?

Wietse Venema
Wietse Venema:

> Raimar Sandner:
> > On Dienstag, 20. Juni 2017 22:33:34 CEST Wietse Venema wrote:
> > > Raimar Sandner:
> > > > Hi,
> > > >
> > > > there seems to be a regression after upgrading from postfix 3.1.4 to 3.2.2
> > > > on arch linux. I'm using virtual aliases with
> > > >  ...
> > > > postfix 3.1 will map  [hidden email] to [hidden email]. This
> > > > is working perfectly fine: When I receive a mail on
> > > > [hidden email], postfix 3.1 logs
> > > >  ...
> > > > This setup stopped working with postfix 3.2 with the exact same
> > > > configuration. The extension is not propagated anymore, postfix 3.2 logs
> > > > ...
> > > > How can I restore the behaviour of postfix 3.1? Your help is greatly
> > > > appreciated! I'm glad to provide more information in case I forgot
> > > > something relevant.
> > > That will require a bugfix. After many years, the address mapping
> > > code needed to be cleaned up, and I thought that all the tests would
> > > have caught any incompatibilities, but apparently not.
> > >
> > > Wietse
> >
> > Thanks for the quick reply! I think I will stick with 3.1 for the time being.
> > Can I help by reporting the bug somewhere besides here?
>
> I already located the problem. We don't have a huge list of bugs.

Patch follows. This was a naive attempt to avoid appending an
extension to an address that already had one. It broke with a
delimiter of '.' because domains also contain '.'.

This reverts the behavior to Postfix 3.1.

        Wietse

--- /var/tmp/postfix-3.3-20170617/src/global/mail_addr_crunch.c 2017-01-27 17:36:22.000000000 -0500
+++ src/global/mail_addr_crunch.c 2017-06-20 19:17:16.000000000 -0400
@@ -120,7 +120,7 @@
  tok822_externalize(extern_addr, tpp[0]->head, TOK822_STR_DEFL);
  canon_addr_external(canon_addr, STR(extern_addr));
  unquote_822_local(intern_addr, STR(canon_addr));
- if (extension && strchr(STR(intern_addr), *extension) == 0) {
+ if (extension) {
     VSTRING_SPACE(intern_addr, extlen + 1);
     if ((ratsign = strrchr(STR(intern_addr), '@')) == 0) {
  vstring_strcat(intern_addr, extension);
Loading...