Return-Path: SRS0... converted to lowercase

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Return-Path: SRS0... converted to lowercase

Wesley van Synio
Hi Postfix users

After a system upgrade of Debian 8 to Debian 9 I have encountered the following problem:

Return-Path that is being added into the mail headers converts lines looks like this:
Return-Path: <srs0=iw5f=o7=DOMAIN=info@OTHERDOMAIN>

Because of the SRS becoming lowercase, this now triggers some spamfilters like SpamAssassin: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7673

I am not sure why/where the problem is being triggered.

Installed postfix version: 3.1.8-0+deb9u1
Before upgrade: 2.11.3-1+deb8u2

PostSRSd does seem to do everything correctly. Relevant entries in my log file:

Dec 27 05:03:16 synio postfix/smtpd[5388]: E45E1E009B: client=camomile.cloud9.net[168.100.1.3]
Dec 27 05:03:16 synio postsrsd[7966]: srs_forward: <[hidden email]> rewritten as <SRS0=nq4B=PE=cloud9.net=owner-postfix-users@MYDOMAIN >
Dec 27 05:03:17 synio postfix/cleanup[7965]: E45E1E009B: message-id=<[hidden email]>
Dec 27 05:03:17 synio postfix/qmgr[2396]: E45E1E009B: from=<srs0=nq4b=pe=cloud9.net=owner-postfix-users@MYDOMAIN>, size=1999, nrcpt=1 (queue active)

As you can see, I believe that PostSRSd does correctly rewrite the address, but then for some reason qmgr receives the address in lowercase?

I tried to figure out what is happening, but I wasn't able to debug the issue myself.

Output of postconf -n: (I replaced my real domain name with MYDOMAIN)

postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_sender_restrictions
postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_client_restrictions
postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_helo_restrictions
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_percent_hack = no
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
home_mailbox = Maildir/
inet_protocols = ipv4
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
message_size_limit = 50000000
milter_default_action = accept
milter_protocol = 2
mydestination = MYDOMAIN, mail. MYDOMAIN , localhost. MYDOMAIN , localhost
mydomain = mail.MYDOMAIN
myhostname = mail.MYDOMAIN
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
non_smtpd_milters = inet:localhost:8891,local:/var/run/milter-greylist/milter-greylist.sock
readme_directory = no
recipient_canonical_classes = envelope_recipient,header_recipient
recipient_canonical_maps = tcp:localhost:10002
recipient_delimiter = +
sender_bcc_maps = hash:/etc/postfix/bcc
sender_canonical_classes = envelope_sender
sender_canonical_maps = tcp:localhost:10001
sender_dependent_default_transport_maps = hash:/etc/postfix/dependent
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_milters = inet:localhost:8891,local:/var/run/milter-greylist/milter-greylist.sock
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_tls_CAfile = /home/synio/ssl.ca
smtpd_tls_cert_file = /etc/postfix/postfix.cert.pem
smtpd_tls_key_file = /etc/postfix/postfix.key.pem
smtpd_tls_mandatory_ciphers = high
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
smtputf8_enable = yes
virtual_alias_maps = hash:/etc/postfix/virtual, regexp:/etc/postfix/virtual-regex

Output of postconf -Mf:

postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_sender_restrictions
postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_client_restrictions
postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_helo_restrictions
smtp       inet  n       -       -       -       -       smtpd
    -o smtpd_sasl_auth_enable=yes
smtps      inet  n       -       -       -       -       smtpd
    -o syslog_name=postfix/smtps
    -o smtpd_tls_wrappermode=yes
    -o smtpd_sasl_auth_enable=yes
    -o smtpd_reject_unlisted_recipient=no
    -o smtpd_client_restrictions=$mua_client_restrictions
    -o smtpd_helo_restrictions=$mua_helo_restrictions
    -o smtpd_sender_restrictions=$mua_sender_restrictions
    -o smtpd_recipient_restrictions=
    -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
    -o milter_macro_daemon_name=ORIGINATING
pickup     unix  n       -       -       60      1       pickup
cleanup    unix  n       -       -       -       0       cleanup
qmgr       unix  n       -       n       300     1       qmgr
tlsmgr     unix  -       -       -       1000?   1       tlsmgr
rewrite    unix  -       -       -       -       -       trivial-rewrite
gounce     unix  -       -       -       -       0       bounce
defer      unix  -       -       -       -       0       bounce
trace      unix  -       -       -       -       0       bounce
verify     unix  -       -       -       -       1       verify
flush      unix  n       -       -       1000?   0       flush
proxymap   unix  -       -       n       -       -       proxymap
proxywrite unix  -       -       n       -       1       proxymap
smtp       unix  -       -       -       -       -       smtp
relay      unix  -       -       -       -       -       smtp
showq      unix  n       -       -       -       -       showq
error      unix  -       -       -       -       -       error
retry      unix  -       -       -       -       -       error
discard    unix  -       -       -       -       -       discard
local      unix  -       n       n       -       -       local
virtual    unix  -       n       n       -       -       virtual
lmtp       unix  -       -       -       -       -       lmtp
anvil      unix  -       -       -       -       1       anvil
scache     unix  -       -       -       -       1       scache
maildrop   unix  -       n       n       -       -       pipe flags=DRhu
    user=vmail argv=/usr/bin/maildrop -d ${recipient}
uucp       unix  -       n       n       -       -       pipe flags=Fqhu
    user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail     unix  -       n       n       -       -       pipe flags=F user=ftn
    argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp      unix  -       n       n       -       -       pipe flags=Fq.
    user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix - n       n       -       2       pipe flags=R
    user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop}
    ${user} ${extension}
mailman    unix  -       n       n       -       -       pipe flags=FR
    user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py ${nexthop}
    ${user}
submission inet  n       -       -       -       -       smtpd
    -o smtpd_sasl_auth_enable=yes

Thank you for looking into it.
Let me know if more info is required.

Also let me know if someone has an idea of where the problem could possibly be?

Kind regards
Wesley S.
Reply | Threaded
Open this post in threaded view
|

Re: Return-Path: SRS0... converted to lowercase

Viktor Dukhovni
On Thu, Dec 27, 2018 at 05:19:16AM +0100, Wesley van Synio wrote:

> Because of the SRS becoming lowercase, ...

> Output of postconf -n:* (I replaced my real domain name with MYDOMAIN)*
>
> recipient_canonical_maps = tcp:localhost:10002
> sender_canonical_classes = envelope_sender
> sender_canonical_maps = tcp:localhost:10001
> smtpd_milters = inet:localhost:8891, local:/var/run/milter-greylist/milter-greylist.sock
> virtual_alias_maps = hash:/etc/postfix/virtual, regexp:/etc/postfix/virtual-regex

The above are the places to look for unwanted case-folding.  The
first and last only affect recipient addresses, so not your immediate
problem, but likely still worth a look for similar issues.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Return-Path: SRS0... converted to lowercase

Wesley van Synio
I still can't find the cause of the problem.

When I disable the sender_canonical_maps then SRS is not working,
and when I then use [hidden email], then case folding is not happening for Return-Path.
So the problem must be in the SRS rewriting or in the connection between PostSRSd and Postfix?

But I already asked the PostSRSd author and also checked the source code and it should work...
Also, the log output mentions a correct rewrite without case folding.

How can I easily debug what Postfix sends and/or receives to/from PostSRSd so I can debug further?
I'm thinking the problem must be located somewhere around there...?

Any other insights would be helpful!

Thank you
Wesley S.

--
Synio
Ilgatlaan 9
3500 Hasselt
0477 71 79 25
Reply | Threaded
Open this post in threaded view
|

Re: Return-Path: SRS0... converted to lowercase

Wietse Venema
Wesley van Synio:

> I still can't find the cause of the problem.
>
> When I disable the sender_canonical_maps then SRS is not working,
> and when I then use [hidden email], then case folding is not happening for
> Return-Path.
> So the problem must be in the SRS rewriting or in the connection between
> PostSRSd and Postfix?
>
> But I already asked the PostSRSd author and also checked the source code
> and it should work...
> Also, the log output mentions a correct rewrite without case folding.
>
> How can I easily debug what Postfix sends and/or receives to/from PostSRSd
> so I can debug further?
> I'm thinking the problem must be located somewhere around there...?
>
> Any other insights would be helpful!

Are you using the TCP map for sender_canonical envelope mapping?
In that case, can you log the input and output? Use a network
sniffer, for example,

tcpdump -i lo -s 0 -w /tmp/foo port 12345

Run it for some time, then stop with ctrl-c.

View with "strings /tmp/foo" or more sophisticated tools.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Return-Path: SRS0... converted to lowercase

Wesley van Synio
Thanks for the idea. I have created a dump using tcpdump and analyzed this using wireshark.

I can see the following transmission:

<< 200 SRS0=sgig=PE=domain.com=[hidden email].
>> get srs0=sgig=pe=domain.com=[hidden email].
<< 200 srs0=sgig=pe=domain.com=[hidden email].

So apparently, Postfix receives the SRS rewritten address,
but then it requests another SRS rewrite from PostSRSd using the already rewritten address (lowercased).

Any idea how this could be possible and how it could be fixed?

Thanks for the feedback so far. It looks like we're on the right track to finding the problem.

Kind regards
Wesley

Op do 27 dec. 2018 om 21:28 schreef Wietse Venema <[hidden email]>:
Wesley van Synio:
> I still can't find the cause of the problem.
>
> When I disable the sender_canonical_maps then SRS is not working,
> and when I then use [hidden email], then case folding is not happening for
> Return-Path.
> So the problem must be in the SRS rewriting or in the connection between
> PostSRSd and Postfix?
>
> But I already asked the PostSRSd author and also checked the source code
> and it should work...
> Also, the log output mentions a correct rewrite without case folding.
>
> How can I easily debug what Postfix sends and/or receives to/from PostSRSd
> so I can debug further?
> I'm thinking the problem must be located somewhere around there...?
>
> Any other insights would be helpful!

Are you using the TCP map for sender_canonical envelope mapping?
In that case, can you log the input and output? Use a network
sniffer, for example,

tcpdump -i lo -s 0 -w /tmp/foo port 12345

Run it for some time, then stop with ctrl-c.

View with "strings /tmp/foo" or more sophisticated tools.

        Wietse


--
Synio
Ilgatlaan 9
3500 Hasselt
0477 71 79 25
Reply | Threaded
Open this post in threaded view
|

Re: Return-Path: SRS0... converted to lowercase

Wietse Venema
Wesley van Synio:

> Thanks for the idea. I have created a dump using tcpdump and analyzed this
> using wireshark.
>
> I can see the following transmission:
>
> *>> get [hidden email] <[hidden email]>.*
> *<< 200 SRS0=sgig=PE=domain.com <http://domain.com>=[hidden email]
> <[hidden email]>.*
> *>> get srs0=sgig=pe=domain.com <http://domain.com>=[hidden email]
> <[hidden email]>.*
> *<< 200 srs0=sgig=pe=domain.com <http://domain.com>=[hidden email]
> <[hidden email]>.*
>
> So apparently, Postfix receives the SRS rewritten address,
> but then it requests another SRS rewrite from PostSRSd using the already
> rewritten address (lowercased).

Canonical map lookups are recursive, therefore the lookup result
is run through the sender canonical mapping again, until the result
stops changing or until Postfix gives up.

I did a quick look over the code and it is very explicitly avoiding
case folding when doing lookups with tcp, pcre, regexp and other
non-indexed tables. So this is non-obvious.

For the heck of it, can you turn on verbose logging on cleanup server:

# postconf -F cleanup/unix/command='cleanup -v -v'
# postfix reload

Repeat one experiment, and send me the logs OFF-LIST, taking care
that it does NOT get messed up with HTTP crap. Suggestion: gzip the
log fragment with verbose logs, then send it as an attachment.

Then turn off the verbose logs:

# postconf -F cleanup/unix/command=cleanup

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Return-Path: SRS0... converted to lowercase

Wesley van Synio
Hi Wietse and others

Thank you for taking a look into my issue.

@Wietse: I have sent you the log files off-list.
Let me know if you are able to find anything out using them?

I also checked the log myself now and I am seeing this:

Dec 27 22:53:09 synio postfix/cleanup[31933]: mail_addr_map: [hidden email] -> 0: SRS0=sgig=PE=domain.com=[hidden email]
Dec 27 22:53:09 synio postfix/cleanup[31933]: dict_tcp_lookup: key srs0=sgig=pe=domain.com=[hidden email]
Dec 27 22:53:09 synio postfix/cleanup[31933]: dict_tcp_lookup: send: get srs0=sgig=pe=domain.com=[hidden email]
Dec 27 22:53:09 synio postfix/cleanup[31933]: dict_tcp_lookup: recv: 200 srs0=sgig=pe=domain.com=[hidden email]
Dec 27 22:53:09 synio postfix/cleanup[31933]: dict_tcp_lookup: found: srs0=sgig=pe=domain.com=[hidden email]

It looks like dict_tcp_lookup uses a lowercase key for some reason.
Maybe a change between older and newer Postfix versions (2.11.3 and 3.1.8) changed a default there?

I don't know much about Postfix, but the source code does mention the following... could it be related?
Is this DICT_FLAG_FOLD_MUL something that I should configure in another way..?

In function dict_tcp_lookup of src/util/dict_tcp.c:

    if (dict->flags & DICT_FLAG_FOLD_MUL) {
if (dict->fold_buf == 0)
    dict->fold_buf = vstring_alloc(10);
vstring_strcpy(dict->fold_buf, key);
key = lowercase(vstring_str(dict->fold_buf));
    }

Thanks for solving the issue with me!

Kind regards
Wesley

--
Synio
Ilgatlaan 9
3500 Hasselt
0477 71 79 25
Reply | Threaded
Open this post in threaded view
|

Re: Return-Path: SRS0... converted to lowercase

Wietse Venema
Wesley van Synio:
> Is this DICT_FLAG_FOLD_MUL something that I should configure in another
> way..?

This is the flag that according to my searches is not set anywhere
in Postfix. That's why I was asking for verbose logs as a last resort.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Return-Path: SRS0... converted to lowercase

Wesley van Synio
Hi Wietse and others

I found the root cause of the problem..

I grepped through the dict and found out that utf8 module is changing the dict settings,
so I wondered if anything would change if I would comment out smtputf8_enable = yes

And a new test has revealed that the problem is fixed without this configuration! See below:

# postmap -v -q "SRS0=xxxx=YY=domain.com=[hidden email]" tcp:localhost:10001
postmap: name_mask: ipv4
postmap: inet_addr_local: configured 5 IPv4 addresses
postmap: dict_open: tcp:localhost:10001
postmap: dict_tcp_lookup: key SRS0=xxxx=YY=domain.com=[hidden email]
postmap: trying... [127.0.0.1]
postmap: dict_tcp_lookup: send: get SRS0=xxxx=YY=domain.com=[hidden email]
postmap: dict_tcp_lookup: recv: 200 SRS1=Ftpn=otherdomain.com==xxxx=YY=domain.com=[hidden email]
postmap: dict_tcp_lookup: found: SRS1=Ftpn=otherdomain.com==xxxx=YY=domain.com=[hidden email]

But... I do want full UTF8 support..

So what is going wrong with the combination of UTF8 + dict_tcp_lookup?
Any ideas how to fix this in my configuration? Or is this a bug?

Kind regards
Wesley S.

Op do 27 dec. 2018 om 23:28 schreef Wietse Venema <[hidden email]>:
Wesley van Synio:
> Is this DICT_FLAG_FOLD_MUL something that I should configure in another
> way..?

This is the flag that according to my searches is not set anywhere
in Postfix. That's why I was asking for verbose logs as a last resort.

        Wietse


--
Synio
Ilgatlaan 9
3500 Hasselt
0477 71 79 25
Reply | Threaded
Open this post in threaded view
|

Re: Return-Path: SRS0... converted to lowercase

Wesley van Synio
Hi Wietse and others

I was looking through src/util/dict/utf8.c and I saw the following piece of code:

    /*
     * Proxy the request with casefolding turned off.
     */
    saved_flags = (dict->flags & DICT_FLAG_FOLD_ANY);
    dict->flags &= ~DICT_FLAG_FOLD_ANY;
    backup = dict->utf8_backup;
    value = backup->lookup(dict, fold_res);
    dict->flags |= saved_flags;

Perhaps something is going wrong there?
I need to brush up on bitwise operations before I can say for sure..
but it does look like it might be the possible culprit?

Kind regards
Wesley

Op do 27 dec. 2018 om 23:39 schreef Wesley van Synio <[hidden email]>:
Hi Wietse and others

I found the root cause of the problem..

I grepped through the dict and found out that utf8 module is changing the dict settings,
so I wondered if anything would change if I would comment out smtputf8_enable = yes

And a new test has revealed that the problem is fixed without this configuration! See below:

# postmap -v -q "SRS0=xxxx=YY=domain.com=[hidden email]" tcp:localhost:10001
postmap: name_mask: ipv4
postmap: inet_addr_local: configured 5 IPv4 addresses
postmap: dict_open: tcp:localhost:10001
postmap: dict_tcp_lookup: key SRS0=xxxx=YY=domain.com=[hidden email]
postmap: trying... [127.0.0.1]
postmap: dict_tcp_lookup: send: get SRS0=xxxx=YY=domain.com=[hidden email]
postmap: dict_tcp_lookup: recv: 200 SRS1=Ftpn=otherdomain.com==xxxx=YY=domain.com=[hidden email]
postmap: dict_tcp_lookup: found: SRS1=Ftpn=otherdomain.com==xxxx=YY=domain.com=[hidden email]

But... I do want full UTF8 support..

So what is going wrong with the combination of UTF8 + dict_tcp_lookup?
Any ideas how to fix this in my configuration? Or is this a bug?

Kind regards
Wesley S.

Op do 27 dec. 2018 om 23:28 schreef Wietse Venema <[hidden email]>:
Wesley van Synio:
> Is this DICT_FLAG_FOLD_MUL something that I should configure in another
> way..?

This is the flag that according to my searches is not set anywhere
in Postfix. That's why I was asking for verbose logs as a last resort.

        Wietse


--
Synio
Ilgatlaan 9
3500 Hasselt
0477 71 79 25


--
Synio
Ilgatlaan 9
3500 Hasselt
0477 71 79 25
Reply | Threaded
Open this post in threaded view
|

Re: Return-Path: SRS0... converted to lowercase

Wesley van Synio
Hi everyone

Upon further inspection, I think that the bitwise operations are correct.. (not 100% sure, but looks alright to me)

And also, the code already goes wrong before checking the DICT_FLAG_FOLD_MUL flag...

Because the source code says:

    if (msg_verbose)
msg_info("%s: key %s", myname, key);

    /*
     * Optionally fold the key.
     */
    if (dict->flags & DICT_FLAG_FOLD_MUL) {

And the printed message with msg_info already contains the wrong (lowercase) key there:

Dec 27 22:53:09 synio postfix/cleanup[31933]: mail_addr_map: [hidden email] -> 0: SRS0=xxxx=yy=domain.com=[hidden email]
Dec 27 22:53:09 synio postfix/cleanup[31933]: dict_tcp_lookup: key srs0=xxxx=yy=domain.com=[hidden email]

So perhaps the UTF8 module changed the case to lowercase before handing it off to dict_tcp_lookup or something..?
I really don't know...

Kind regards
Wesley S.

Op do 27 dec. 2018 om 23:48 schreef Wesley van Synio <[hidden email]>:
Hi Wietse and others

I was looking through src/util/dict/utf8.c and I saw the following piece of code:

    /*
     * Proxy the request with casefolding turned off.
     */
    saved_flags = (dict->flags & DICT_FLAG_FOLD_ANY);
    dict->flags &= ~DICT_FLAG_FOLD_ANY;
    backup = dict->utf8_backup;
    value = backup->lookup(dict, fold_res);
    dict->flags |= saved_flags;

Perhaps something is going wrong there?
I need to brush up on bitwise operations before I can say for sure..
but it does look like it might be the possible culprit?

Kind regards
Wesley

Op do 27 dec. 2018 om 23:39 schreef Wesley van Synio <[hidden email]>:
Hi Wietse and others

I found the root cause of the problem..

I grepped through the dict and found out that utf8 module is changing the dict settings,
so I wondered if anything would change if I would comment out smtputf8_enable = yes

And a new test has revealed that the problem is fixed without this configuration! See below:

# postmap -v -q "SRS0=xxxx=YY=domain.com=[hidden email]" tcp:localhost:10001
postmap: name_mask: ipv4
postmap: inet_addr_local: configured 5 IPv4 addresses
postmap: dict_open: tcp:localhost:10001
postmap: dict_tcp_lookup: key SRS0=xxxx=YY=domain.com=[hidden email]
postmap: trying... [127.0.0.1]
postmap: dict_tcp_lookup: send: get SRS0=xxxx=YY=domain.com=[hidden email]
postmap: dict_tcp_lookup: recv: 200 SRS1=Ftpn=otherdomain.com==xxxx=YY=domain.com=[hidden email]
postmap: dict_tcp_lookup: found: SRS1=Ftpn=otherdomain.com==xxxx=YY=domain.com=[hidden email]

But... I do want full UTF8 support..

So what is going wrong with the combination of UTF8 + dict_tcp_lookup?
Any ideas how to fix this in my configuration? Or is this a bug?

Kind regards
Wesley S.

Op do 27 dec. 2018 om 23:28 schreef Wietse Venema <[hidden email]>:
Wesley van Synio:
> Is this DICT_FLAG_FOLD_MUL something that I should configure in another
> way..?

This is the flag that according to my searches is not set anywhere
in Postfix. That's why I was asking for verbose logs as a last resort.

        Wietse


--
Synio
Ilgatlaan 9
3500 Hasselt
0477 71 79 25


--
Synio
Ilgatlaan 9
3500 Hasselt
0477 71 79 25


--
Synio
Ilgatlaan 9
3500 Hasselt
0477 71 79 25
Reply | Threaded
Open this post in threaded view
|

Re: Return-Path: SRS0... converted to lowercase

Wietse Venema
In reply to this post by Wesley van Synio
Fixed in Postfix 3.4, but for some reason never made it into
the Postfix stable releases. Fixed by adding one set of ().

20180707

        Bugfix (introduced: Postfix 3.0): with smtputf8_enable=yes,
        table lookups could casefold the search string when searching
        a lookup table that does not use fixed-string keys (regexp,
        pcre, tcp, etc.). Historically, Postfix would not case-fold
        the search string with such tables. File: util/dict_utf8.c.

--- dict_utf8.c 2015-02-03 11:19:19.000000000 -0500
+++ ../../../postfix-3.4-20181226/src/util/dict_utf8.c 2018-07-07 17:07:00.000000000 -0400
@@ -104,8 +109,9 @@
     /*
      * Casefold UTF-8.
      */
-    if (fold_flag != 0 && (fold_flag & (dict->flags & DICT_FLAG_FIXED) ?
-   DICT_FLAG_FOLD_FIX : DICT_FLAG_FOLD_MUL)) {
+    if (fold_flag != 0
+ && (fold_flag & ((dict->flags & DICT_FLAG_FIXED) ?
+ DICT_FLAG_FOLD_FIX : DICT_FLAG_FOLD_MUL))) {
  if (dict->fold_buf == 0)
     dict->fold_buf = vstring_alloc(10);
  return (casefold(dict->fold_buf, string));

Reply | Threaded
Open this post in threaded view
|

Re: Return-Path: SRS0... converted to lowercase

Wesley van Synio
Hi Wietse

Great! So it looks like it has been fixed in later versions of Postfix...

I'm guessing the Postfix version in Debian won't receive this fix anytime soon? Still at 3.1.8 there.
Not sure if this bug is something that they would/should backport?
But perhaps that's a question for some kind of Debian mailing list instead..

Thank you for figuring out my problem.

Kind regards
Wesley S.

Op vr 28 dec. 2018 om 00:29 schreef Wietse Venema <[hidden email]>:
Fixed in Postfix 3.4, but for some reason never made it into
the Postfix stable releases. Fixed by adding one set of ().

20180707

        Bugfix (introduced: Postfix 3.0): with smtputf8_enable=yes,
        table lookups could casefold the search string when searching
        a lookup table that does not use fixed-string keys (regexp,
        pcre, tcp, etc.). Historically, Postfix would not case-fold
        the search string with such tables. File: util/dict_utf8.c.

--- dict_utf8.c 2015-02-03 11:19:19.000000000 -0500
+++ ../../../postfix-3.4-20181226/src/util/dict_utf8.c  2018-07-07 17:07:00.000000000 -0400
@@ -104,8 +109,9 @@
     /*
      * Casefold UTF-8.
      */
-    if (fold_flag != 0 && (fold_flag & (dict->flags & DICT_FLAG_FIXED) ?
-                          DICT_FLAG_FOLD_FIX : DICT_FLAG_FOLD_MUL)) {
+    if (fold_flag != 0
+       && (fold_flag & ((dict->flags & DICT_FLAG_FIXED) ?
+                        DICT_FLAG_FOLD_FIX : DICT_FLAG_FOLD_MUL))) {
        if (dict->fold_buf == 0)
            dict->fold_buf = vstring_alloc(10);
        return (casefold(dict->fold_buf, string));



--
Synio
Ilgatlaan 9
3500 Hasselt
0477 71 79 25
Reply | Threaded
Open this post in threaded view
|

Re: Return-Path: SRS0... converted to lowercase

Wietse Venema
Wesley van Synio:
> Hi Wietse
>
> Great! So it looks like it has been fixed in later versions of Postfix...
>
> I'm guessing the Postfix version in Debian won't receive this fix anytime
> soon? Still at 3.1.8 there.
> Not sure if this bug is something that they would/should backport?
> But perhaps that's a question for some kind of Debian mailing list instead..

I expect that there will be a postfix-3.1.11 release in January
before the Postfix 3.4 stable release comes out. No idea when/if
Debian will pick it up.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Return-Path: SRS0... converted to lowercase

Scott Kitterman-4


On December 27, 2018 11:52:03 PM UTC, Wietse Venema <[hidden email]> wrote:

>Wesley van Synio:
>> Hi Wietse
>>
>> Great! So it looks like it has been fixed in later versions of
>Postfix...
>>
>> I'm guessing the Postfix version in Debian won't receive this fix
>anytime
>> soon? Still at 3.1.8 there.
>> Not sure if this bug is something that they would/should backport?
>> But perhaps that's a question for some kind of Debian mailing list
>instead..
>
>I expect that there will be a postfix-3.1.11 release in January
>before the Postfix 3.4 stable release comes out. No idea when/if
>Debian will pick it up.

I usually pick up the stable updates for Debian.  I've been short on time recently, so I'm behind.  No one in particular you need to bug.  I'm aware of it.

Scott K