Part in multipart contains a dot alone in a line, transmitted as is, considered as end of transmission by clients
lpointal opened this issue · 7 comments
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.
Same email received correctly by another list member, via another path — seem some intermediate email processing (amavis, cisco?) did the bad job.
One difference between the two paths, the other list member has the receive option activated to store attachements on sympa server.
Oups RFC5231 not 5321.
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.
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.
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.
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…
- look at my emails with another imap client (webmail Zimbra), email is truncated in the same way - problem is not from client.
- look at list archives… email is stored complete.
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