Bug 12142

Summary:	Bugzilla: Email seems to be line-wrapped when piped into email_in.pl
Product:	Infrastructure	Reporter:	Michael Tremer <michael.tremer>
Component:	Mail & Mailing Lists	Assignee:	Peter Müller <peter.mueller>
Status:	ASSIGNED ---	QA Contact:	Peter Müller <peter.mueller>
Severity:	Minor Usability
Priority:	Will only affect a few users
Version:	unspecified
Hardware:	unspecified
OS:	Unspecified

Description Michael Tremer 2019-08-22 14:37:48 UTC

When I send an email to bugzilla@ipfire.org, it seems to be getting parsed incorrectly when sent from Apple Mail.

Bugzilla uses some variables so that the bug is being put into the correct product and component. Those cannot be parsed.

I guess the following error message back:

> There is no component named 'clamav > > https://blog.clamav.net/2019/08/clamav-01014-security-patch-release-has.html > > ClamAV 0.101.4 security patch release has been published > > Today we have published the ClamAV 0.101.4 security patch release. > > 0.101.4 > > > ClamAV 0.101.4 is a security patch release that addresses the following issues. > An out of bounds write was possible within ClamAV's NSIS bzip2 library when attempting decompression in cases where the number of selectors exceeded the max limit set by the library (CVE-2019-12900). The issue has been resolved by respecting that limit. > > Thanks to Martin Simmons for reporting the issue here . > The zip bomb vulnerability mitigated in 0.101.3 has been assigned the CVE identifier CVE-2019-12625. Unfortunately, a workaround for the zip-bomb mitigation was immediately identified. To remediate the zip-bomb scan time issue, a scan time limit has been introduced in 0.101.4. This limit now resolves ClamAV's vulnerability to CVE-2019-12625. > > The default scan time limit is 2 minutes (120000 milliseconds). > > To customize the time limit: > - use the clamscan --max-scantime option > - use the clamd MaxScanTime config option > > Libclamav users may customize the time limit using the cl_engine_set_num function. For example: > > C > cl_engine_set_num(engine, CL_ENGINE_MAX_SCANTIME, time_limit_milliseconds) > > Thanks to David Fifield for reviewing the zip-bomb mitigation in 0.101.3 and reporting the issue. > As usual, ClamAV may be downloaded from https://www.clamav.net/downloads , and discussion should take place on the ClamAV-Users list . Thanks! _______________________________________________' in the 'IPFire' product. 

The original header was:

@product = IPFire
@version = 3
@component = clamav

It seems that the email is formatted differently. When sent from Roundcube this works okay.

I would like to see this fixed, although it might only affect my client. However that is a popular one and I am not sure how many other MUAs are affected, too.

Comment 1 Michael Tremer 2019-10-03 11:27:14 UTC

I ran into this again today. If you have a chance, please move this up on your TODO list.

Comment 2 Peter Müller 2019-10-13 11:28:20 UTC

Okay, I will see what I can do about this.

Comment 3 Peter Müller 2019-10-13 11:49:32 UTC

Actually, this reminds me of some line-wrapping issues we've had with Thunderbird: https://wiki.ipfire.org/devel/send-tb-patches

Comment 4 Peter Müller 2019-10-13 12:02:11 UTC

After some tests, I am pretty sure this is a MUA problem, especially related to HTML mails (which I strongly recommend against for obvious reasons).

Maybe this helps: https://discussions.apple.com/thread/977610

Comment 5 Michael Tremer 2019-10-13 16:19:01 UTC

That link does not address the problem. It talks about text formatting, but the text is actually formatted and Bugzilla does not see any line breaks any more. In my book that is a different problem.

Although this might be a MUA problem, I need this to be fixed to be able to communicate with Bugzilla. I am not sure if there are more MUAs that are affected by this.

Comment 6 Peter Müller 2019-10-18 15:19:05 UTC

Just testing...

Comment 7 Peter Müller 2019-10-18 15:24:15 UTC

Well, at least submitting mails to Bugzilla sent from Thunderbird works,
as tested by the previous comment. :-)

I am sorry, but in my point of view, Apple Mail misbehaves here. If
you could send me the full copy of a mail causing this error, there
may or may not be some useful information in it (CRLF issues??), but
a MTA does message transport, not message manipulation.

If the MUA's programmers are brave or stupid enough not to follow the
RFCs, cleaning the mess is their job. As a postmaster, I do not care.