sympa-community / sympa

Sympa, Mailing List Management Software
https://www.sympa.community/sympa
GNU General Public License v2.0
237 stars 94 forks source link

Part in multipart contains a dot alone in a line, transmitted as is, considered as end of transmission by clients #1850

Closed lpointal closed 3 weeks ago

lpointal commented 3 weeks ago

A post contains data as part (see below for part details), where line truncation provoke placement of an alone dot in a line.

Seem targets of the post receive the dot as is, which is considered as the end of content in SMTP protocol (see rfc5321 section 4.5.2). So client emails receive

Version

Sympa 6.2.70

From firefox debug logs: jquery.js 3.6.0 jquery-migrate.js 1.4.1 jquery-ui.js 1.12.1 jquery.jqplot.min.js 1.0.8 what-input 4.2.0 jqplot.categoryAxisRenderer.min.js 1.0.8 jqplot.barRenderer.min.js 1.0.8 jqplot.canvasAxisTickRenderer.min.js 1.0.8 jqplot.canvasTextRenderer.min.js 1.0.8 jquery.minicolors.min.js 2.3 respond.min.js 1.4.2 foundation.min.js 6.4.2

No information about the host environment (not managed by me).

Installation method

Dont know.

Expected behavior

Dot alone in a line be doubled when transmitting.

Actual behavior

Dot is not doubled, client receiving the email consider an end of transmission.

Steps to reproduce

Difficult, must find a multipart content with a part (html part in utf8 encoding, with quoted-printable escape in that case) where the truncation of a line provoke the presence of a dot alone in a line.

Additional information

Sorry, the original document triggering the bug contains confidential data I cannot put in public bug tracking.

lpointal commented 3 weeks ago

Same email received correctly by another list member, via another path — seem some intermediate email processing (amavis, cisco?) did the bad job.

lpointal commented 3 weeks ago

One difference between the two paths, the other list member has the receive option activated to store attachements on sympa server.

lpointal commented 3 weeks ago

Oups RFC5231 not 5321.

ikedas commented 3 weeks ago

Hi @lpointal ,

Actual behavior Dot is not doubled, client receiving the email consider an end of transmission.

Steps to reproduce Difficult, must find a multipart content with a part (html part in utf8 encoding, with quoted-printable escape in that case) where the truncation of a line provoke the presence of a dot alone in a line.

Please describe specifically what you did and what you saw as a result.

To ask question better, please refer to this page for example.

lpointal commented 3 weeks ago

Reading emails headers, the one without attachment (stored on the server) have:

X-Amp-Result: LOWRISK
X-Amp-File-Uploaded: False

And the one which should contain attachment:

X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False

So the problem of early end of mail seem coming from sympa output, not from intermediate processing. I reopen the ticket.

ikedas commented 3 weeks ago

Please show us what you did specifically, i.e.: "I launched an application named XXXX, selected a menu item XXX/XXX, entered a text 'XXXX' into the XXXX field, clicked XXXX button, ...".

And show us what you see specifically, i.e. the very thing you see on the screen you are looking at.

lpointal commented 3 weeks ago

Hum, I did very few on my side: from Thunderbird click on an email received from a sympa mailing list, the displayed email is abruptly truncated in the middle of the content. And, as I wrote, it is difficult to reproduce.

Then I investigate why…

So there is a problem between sympa and my reception. Look at complete emails sources, in sympa archive and in thunderbird. In the stored email on sympa I identified the dot alone in an html multipart part, in the line immediately after the cut-out or the content when it is displayed (there was recent post on HN about a similar problem).

I opened the bug report, then learn that somebody else has correctly received the email (?). Ask for his full email source, this person have the option to store attachement on sympa server.

(below i replaced internal informations by *)

When transmitted, the email with attachement stored on the server have its content cut after column 77.

--------------SLoMwcWDv3Skc0C917f5zzPi
Content-Type: multipart/related;
 boundary="------------p74oCK0oFOOocQUHHq1zOJZA"

--------------p74oCK0oFOOocQUHHq1zOJZA
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
    <p>Bonjour,<br>
      <br>
      Voici la fiche d'accueil de : M. T***** *** *********, permanent
      IR, =C3=A9quipe *****, =C3=A0 compter du **/**/****, encadrante *-*.
      *********<br>
    </p>
    <p>Ci-joint la fiche accueil et les demandes d'acc=C3=A8s aux b=C3=A2ti=
ments.<br>
      <br>
      Vous en souhaitant bonne r=C3=A9ception.<br>
      <br>
      Je vous remercie.<br>
      <br>
      Bonne journ=C3=A9e </p>
…

When transmitted, the email with attachement incorported have its content cut after column 75.

--------------SLoMwcWDv3Skc0C917f5zzPi
Content-Type: multipart/related;
 boundary="------------p74oCK0oFOOocQUHHq1zOJZA"

--------------p74oCK0oFOOocQUHHq1zOJZA
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF=
-8">
  </head>
  <body>
    <p>Bonjour,<br>
      <br>
      Voici la fiche d'accueil de : M. T***** *** *********, permanent
      IR, =C3=A9quipe *****, =C3=A0 compter du **/**/****, encadrante *-*=

I had suspicions about intermediate security tools around emails transmissions in my university… and i will open a ticket for that because the header before these tools:

X-Amp-Result: LOWRISK
X-Amp-File-Uploaded: False

Become, after security filtering:

X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False