16.04, problem with cyrillic alerts from amavis

Bug #1676805 reported by sles
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
amavisd-new (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Hello!

In 12.04 everything works just fine.
I have ru_RU templates directory with charset file
with line UTF-8 in it.
In /etc/amavis/conf.d/30-template_localization
I have
$hdr_encoding = 'utf-8';
$bdy_encoding = 'utf-8';

I this case encoding of message is set to utf-8 ,
but message is broken, i.e. it is not in utf-8.

if I set
$bdy_encoding = 'iso-8859-1';
then there is utf-8 readable message, but just wrong info about encoding in it.

Everything like described here in last message:

http://serverdoma.ru/viewtopic.php?f=39&t=1027

I.e. amavis shipped with 16.04 is broken...

Thank you!

Revision history for this message
sles (slesru) wrote :

OK, this is not real fix, but it fixes things for me, because I use utf8...

 diff -ur amavisd-new-dist amavisd-new
--- amavisd-new-dist 2017-03-29 09:13:53.716398825 +0400
+++ amavisd-new 2017-03-29 09:40:45.796746725 +0400
@@ -10556,14 +10556,14 @@
     }
   }
   $m_hdr = safe_encode_utf8($m_hdr) if defined $m_hdr;
- $m_body = safe_encode(c('bdy_encoding'), $m_body) if defined $m_body;
+ #$m_body = safe_encode(c('bdy_encoding'), $m_body) if defined $m_body;
   # make sure _our_ source line number is reported in case of failure
   my $multipart_cnt = 0;
   $mime_type = 'multipart/mixed' if !defined $mime_type;
   eval {
     # RFC 6522: 7bit should always be adequate for multipart/report encoding
     $entity = MIME::Entity->build(
- Type => $mime_type, Encoding => '8bit',
+ Type => $mime_type, Encoding => '7bit',
       'X-Mailer' => undef);
     1;
   } or do {

Revision history for this message
Serge Braichuk (sergyb) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in amavisd-new (Ubuntu):
status: New → Confirmed
Revision history for this message
sles (slesru) wrote :

Serge, in this procedure I have
 $s = safe_encode_utf8($s) if $n eq 'log_templ' || 'log_recip_templ';
i.e. not safe_encode_utf8_inplace
is it correct to change it to
safe_encode_utf8($s) if $n eq 'log_templ' || $n eq 'log_recip_templ';

?
Thank you!

Revision history for this message
Serge Braichuk (sergyb) wrote :

Sure it is correct.
Sorry, the patch is for the current latest stable amavisd-new-2.11.0.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi sles,
as with your other bug (so mostly the same answer) I appreciate taking the time to report this bug and helping to make Ubuntu better. I like the pre-debug and change suggestions and I'm sure it'll be helpful to others experiencing the same issue.

On this one you should as with the other (bug 1733834) engage with upstream on this as in [1].
I can only encourage to go on with that path or one will end up with an un-maintainable delta.

This sounds like an upstream bug to me. If this is confirmed as an upstream bug, the best route to getting it fixed in Ubuntu in this case would be to pull and backport fixes once available there. Otherwise, I'm not sure what we can do directly in Ubuntu to fix the problem without the high risk of getting incompatible.

If you do end up filing an upstream bug, please link to it from here. Although as I find in [1] there isn't a real bug tracker - so the ML links you had are likely all we get.
You might update here once one of them resolve.

You might also want to report to Debian as well to make them aware and link that bug here - but they very likely would have the same position on this.

[1]: https://www.ijs.si/software/amavisd/#faq-trouble

tags: added: need-upstream-report
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Note: I just meregd 2.11.0 for the next Ubuntu release, so patches against that are fine to get things started - but should have some sort of upstream backing to not end up as maintenance dept.

I know how this feels with my german chars äöü sometimes causing such things and you feel nobody case about you (cyrillic in your case), but without an upstream-ack on this I'd consider the risk to high to cause more regressions later on (especially as I have to admit to not use amavis a lot, so my risk assesment would be guessing at best).

Revision history for this message
sles (slesru) wrote :

Serge, thank you!

Just because I run avamisd-new in production only really available time is January 1st.
Thank you!

ChristianEhrhardt, sure, if Serge's patch will work for me I'll post confirmation to amavisd-new developers mail list and ask fo inclusion.

Thank you!

Revision history for this message
Serge Braichuk (sergyb) wrote :

I see this as upstream bug too.

So I posted description of it on amavis-users list:

https://lists.amavis.org/pipermail/amavis-users/2017-November/005115.html

and have no response.

It does not contain all information as required by amavisd-new developers in

https://www.ijs.si/software/amavisd/#faq-trouble

but I think that this is not need as this bug is a simple logical error.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Thank you both, let us know if there is any response.

Lets say if nothing at all comes back we unfortunately need to consider patching with a Delta in Ubuntu/Debian, but giving upstream ~4 weeks or so seems fair.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.