[exim-dev] [Bug 1863] New: add_header = $spam_report puts 8-…

トップ ページ
このメッセージを削除
このメッセージに返信
著者: admin
日付:  
To: exim-dev
新しいトピック: [exim-dev] [Bug 1863] add_header = $spam_report puts 8-bit encoded data into the header
題目: [exim-dev] [Bug 1863] New: add_header = $spam_report puts 8-bit encoded data into the header
https://bugs.exim.org/show_bug.cgi?id=1863

            Bug ID: 1863
           Summary: add_header = $spam_report puts 8-bit encoded data into
                    the header
           Product: Exim
           Version: 4.84
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Content Scanning
          Assignee: tom@???
          Reporter: martin.von.wittich@???
                CC: exim-dev@???


We have configured our exim to use SpamAssassin, and to add the $spam_report to
our mail headers:

> acl_smtp_data = acl_check_data
>
> [...]
>
> acl_check_data:
>
> [...]
>
>     # Spamassassin aufrufen und Report in Mailheader einfügen
>     warn
>       #!authenticated = *
>       #!hosts = +lan_hosts
>       spam = debian-spamd:true
>       add_header = ${sg{$spam_report}{\n\\s+X-Spam-}{\nX-Spam-}}

>
> [...]


The servers use a German locale, and this causes SpamAssassin to use the
translated rule descriptions from the ISO-8859-1 encoded file
/var/lib/spamassassin/3.004000/updates_spamassassin_org/30_text_de.cf, and
these may contain German umlauts:

> dev2.iserv.eu ~ # file /var/lib/spamassassin/3.004000/updates_spamassassin_org/30_text_de.cf
> /var/lib/spamassassin/3.004000/updates_spamassassin_org/30_text_de.cf: ISO-8859 text


> dev2.iserv.eu ~ # grep GTUBE /var/lib/spamassassin/3.004000/updates_spamassassin_org/30_text_de.cf | xxd
> 0000000: 6c61 6e67 2064 6520 6465 7363 7269 6265  lang de describe
> 0000010: 2047 5455 4245 2054 6573 7420 7a75 7220   GTUBE Test zur 
> 0000020: 5072 fc66 756e 6720 766f 6e20 416e 7469  Pr.fung von Anti
> 0000030: 2d53 7061 6d2d 536f 6674 7761 7265 0a    -Spam-Software.


Unfortunately exim just puts these 8-bit strings directly into the mail header
without encoding the 8-bit characters, which violates the RFC. I looked for a
way to disable the description translations in SpamAssassin (I don't think
they're very useful - the kind of people who read the spam report in a mail
header are likely to be comfortable with English descriptions), but I haven't
found a way to do that.

A possible workaround on the exim side is to use ${map} and ${encode}:

> add_header = ${map{<\n ${sg{$spam_report}{\n\\s+X-Spam-}{\nX-Spam-}}}{${escape:$item}}}


I'm not sure though whether this relatively complicated workaround should be
necessary. The documentation[1] contains an example where $spam_report is added
as a header without escaping it:

> # put headers in all messages (no matter if spam or not)
> warn  spam = nobody:true
>       add_header = X-Spam-Score: $spam_score ($spam_bar)
>       add_header = X-Spam-Report: $spam_report


I think that either $spam_report should behave nice enough so that escaping
isn't necessary, or add_header should automatically escape 8-bit characters, or
the documentation should be amended with the ${map}/${escape} workaround
(beware though: I just came up with that, haven't tested it very much yet ^^)
so that the example code doesn't break when it's run on a server with a
different locale.

Information about the Linux distribution and exim version:

dev2.iserv.eu ~ # dpkg -l | grep exim4
ii  exim4                                       4.84.2-1                       
             all          metapackage to ease Exim MTA (v4) installation
ii  exim4-base                                  4.84.2-1                       
             i386         support files for all Exim MTA (v4) packages
ii  exim4-config                                4.84.2-1                       
             all          configuration for the Exim MTA (v4)
ii  exim4-daemon-heavy                          4.84.2-1                       
             i386         Exim MTA (v4) daemon with extended features,
including exiscan-acl


dev2.iserv.eu ~ # apt-cache policy exim4
exim4:
  Installiert:           4.84.2-1
  Installationskandidat: 4.84.2-1
  Versionstabelle:
     4.87-3~bpo8+1 0
        100 http://ftp.de.debian.org/debian/ jessie-backports/main i386
Packages
 *** 4.84.2-1 0
        500 http://ftp.de.debian.org/debian/ jessie/main i386 Packages
        500 http://security.debian.org/ jessie/updates/main i386 Packages
        100 /var/lib/dpkg/status


dev2.iserv.eu ~ # exim -bV
Exim version 4.84_2 #1 built 13-Mar-2016 22:18:25
Copyright (c) University of Cambridge, 1995 - 2014
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2014
Berkeley DB: Berkeley DB 5.3.28: (September 9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS
move_frozen_messages Content_Scanning DKIM Old_Demime PRDR OCSP
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /etc/exim4/exim4.conf


[1]
http://www.exim.org/exim-html-current/doc/html/spec_html/ch-content_scanning_at_acl_time.html

--
You are receiving this mail because:
You are on the CC list for the bug.