[GH-ISSUE #501] No support for RFC5321 4.5.2 Transparancy causing double periods #327

Closed
opened 2026-03-15 13:53:42 +03:00 by kerem · 8 comments
Owner

Originally created by @AlexHaan-i on GitHub (May 27, 2025).
Original GitHub issue: https://github.com/axllent/mailpit/issues/501

RFC5321 defines Transparancy in https://www.rfc-editor.org/rfc/rfc5321#section-4.5.2:

  • Before sending a line of mail text, the SMTP client checks the
    first character of the line. If it is a period, one additional
    period is inserted at the beginning of the line.

  • When a line of mail text is received by the SMTP server, it checks
    the line. If the line is composed of a single period, it is
    treated as the end of mail indicator. If the first character is a
    period and there are other characters on the line, the first
    character is deleted.

So, when a period character ends up at the start of a line in the e-mail source, the sending client will insert an extra period.
It's up to the SMTP server to remove that again.

So, if I have a url (either as normal text, or as attribute for an image or link) and one of its periods ends up at the start of a line, another period is added.
That extra period isn't stripped creating an invalid url.

I'm running version v1.25.1 of Mailpit.

Ps. Before, we used Mailhog. I reported the same issue there 2 years ago. Mailpit offers some benefits. Only now I encountered the same issue here.

Originally created by @AlexHaan-i on GitHub (May 27, 2025). Original GitHub issue: https://github.com/axllent/mailpit/issues/501 RFC5321 defines Transparancy in https://www.rfc-editor.org/rfc/rfc5321#section-4.5.2: > - Before sending a line of mail text, the SMTP client checks the > first character of the line. If it is a period, one additional > period is inserted at the beginning of the line. > > - When a line of mail text is received by the SMTP server, it checks > the line. If the line is composed of a single period, it is > treated as the end of mail indicator. If the first character is a > period and there are other characters on the line, the first > character is deleted. So, when a period character ends up at the start of a line in the e-mail source, the sending client will insert an extra period. It's up to the SMTP server to remove that again. So, if I have a url (either as normal text, or as attribute for an image or link) and one of its periods ends up at the start of a line, another period is added. That extra period isn't stripped creating an invalid url. I'm running version v1.25.1 of Mailpit. Ps. Before, we used Mailhog. I reported the same issue there 2 years ago. Mailpit offers some benefits. Only now I encountered the same issue here.
kerem 2026-03-15 13:53:42 +03:00
  • closed this issue
  • added the
    invalid
    label
Author
Owner

@axllent commented on GitHub (May 27, 2025):

Hi. To help me narrow down where you are seeing this issue:

telnet localhost 1025
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 thinkpad Mailpit ESMTP Service ready
EHLO server
250-thinkpad greets server
250-SIZE 0
250-ENHANCEDSTATUSCODES
250 SMTPUTF8
MAIL FROM:<user@example.com>
250 2.1.0 Ok
RCPT TO:<to@example.com>
250 2.1.5 Ok
DATA
354 Start mail input; end with <CR><LF>.<CR><LF>
Subject: Testing .

This is a test.
.This one started with a dot.
..This has a double-dot.
...This has three dots
.
250 2.0.0 Ok: queued as NzovvwihaqWJSpxaKFrzJS
quit
221 2.0.0 thinkpad Mailpit ESMTP Service closing transmission channel
Connection closed by foreign host.

The received message source:

Bcc: to@example.com
Message-ID: <cXGH5szNgHqHfNxSUToi7w@mailpit>
Return-Path: <user@example.com>
Received: from server (localhost [127.0.0.1])
        by thinkpad (Mailpit) with SMTP
        for <to@example.com>; Tue, 27 May 2025 21:54:33 +1200 (NZST)
Subject: Testing .

This is a test.
This one started with a dot.
.This has a double-dot.
..This has three dots

It appears new lines within the body starting with a . are in fact "stripped", so where is the issue here?

<!-- gh-comment-id:2911932705 --> @axllent commented on GitHub (May 27, 2025): Hi. To help me narrow down where you are seeing this issue: ```shell telnet localhost 1025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 thinkpad Mailpit ESMTP Service ready EHLO server 250-thinkpad greets server 250-SIZE 0 250-ENHANCEDSTATUSCODES 250 SMTPUTF8 MAIL FROM:<user@example.com> 250 2.1.0 Ok RCPT TO:<to@example.com> 250 2.1.5 Ok DATA 354 Start mail input; end with <CR><LF>.<CR><LF> Subject: Testing . This is a test. .This one started with a dot. ..This has a double-dot. ...This has three dots . 250 2.0.0 Ok: queued as NzovvwihaqWJSpxaKFrzJS quit 221 2.0.0 thinkpad Mailpit ESMTP Service closing transmission channel Connection closed by foreign host. ``` The received message source: ``` Bcc: to@example.com Message-ID: <cXGH5szNgHqHfNxSUToi7w@mailpit> Return-Path: <user@example.com> Received: from server (localhost [127.0.0.1]) by thinkpad (Mailpit) with SMTP for <to@example.com>; Tue, 27 May 2025 21:54:33 +1200 (NZST) Subject: Testing . This is a test. This one started with a dot. .This has a double-dot. ..This has three dots ``` It appears new lines within the body starting with a `.` are in fact "stripped", so where is the issue here?
Author
Owner

@AlexHaan-i commented on GitHub (May 27, 2025):

Thank you for your quick response.

I'm seeing this in the HTML view of a mail. Where a long line is wrapped over multiple lines.

This my (stripped) RAW message as shown in the webinterface:

Date: ...
Subject: mailer test
From: ...
To: ...
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: ...

<body>
this is a long line, longer even, lon <a href=3D"https://github=
..com/axllent/mailpit/issues/501">link</a>
</body>

The resulting "HTML source" is then:

<body>
this is a long line, longer even, lon <a href="https://github..com/axllent/mailpit/issues/501">link</a>
</body>
<!-- gh-comment-id:2912038023 --> @AlexHaan-i commented on GitHub (May 27, 2025): Thank you for your quick response. I'm seeing this in the HTML view of a mail. Where a long line is wrapped over multiple lines. This my (stripped) RAW message as shown in the webinterface: ``` Date: ... Subject: mailer test From: ... To: ... MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: ... <body> this is a long line, longer even, lon <a href=3D"https://github= ..com/axllent/mailpit/issues/501">link</a> </body> ``` The resulting "HTML source" is then: ``` <body> this is a long line, longer even, lon <a href="https://github..com/axllent/mailpit/issues/501">link</a> </body> ```
Author
Owner

@axllent commented on GitHub (May 27, 2025):

Right. I strongly suspect that the issue might originate from whatever is creating this formatted email. If the library is wrapping the long lines and adding the extra dot, then passing it to a sendmail client which then adds another dot during the SMTP transaction, then you're going to end up with a double dot (because there are now actually 3 dots on the SMTP transaction). This is not sendmail's fault, nor the mailserver, but rather the library you're using.

I have seen this in the past, but I can't recall which PHP library that was (I suspect symfony, but I'm not sure). It's fine if the library is actually doing the SMTP connection itself, but not if the message is just being passed through to sendmail which does that for you.

<!-- gh-comment-id:2912111219 --> @axllent commented on GitHub (May 27, 2025): Right. I strongly suspect that the issue might originate from whatever is creating this formatted email. If the library is wrapping the long lines and adding the extra dot, then passing it to a sendmail client which then adds another dot during the SMTP transaction, then you're going to end up with a double dot (because there are now actually 3 dots on the SMTP transaction). This is not sendmail's fault, nor the mailserver, but rather the library you're using. I have seen this in the past, but I can't recall which PHP library that was (I suspect symfony, but I'm not sure). It's fine if the library is actually doing the SMTP connection itself, but not if the message is just being passed through to sendmail which does that for you.
Author
Owner

@axllent commented on GitHub (May 27, 2025):

Ahh yes, symfony, see https://github.com/symfony/symfony/issues/50875

You have to include the-i in the mailer config. The symfony mailer has a really basic system where it will add the extra dot if there's no -i in the command.

<!-- gh-comment-id:2912126254 --> @axllent commented on GitHub (May 27, 2025): Ahh yes, symfony, see https://github.com/symfony/symfony/issues/50875 You have to include the`-i` in the mailer config. The symfony mailer has a really basic system where it will add the extra dot if there's no `-i` in the command.
Author
Owner

@axllent commented on GitHub (May 27, 2025):

Also see #350.

<!-- gh-comment-id:2912143791 --> @axllent commented on GitHub (May 27, 2025): Also see #350.
Author
Owner

@AlexHaan-i commented on GitHub (May 27, 2025):

Thank you for your response. I should have searched for 'dots'...

That sendmail -i parameter is quite confusing; https://linux.die.net/man/8/sendmail.sendmail :

Ignore dots alone on lines by themselves in incoming messages. This should be set if you are reading data from a file.

My message doesn't have an alone dot though.

But setting up PHP(.ini), for our Docker setup as follows does indeed strip that dot;

sendmail_path = '(echo "X-Tags: somecustomtaghere"; cat -) | /usr/local/bin/mailpit sendmail -t -i -S mailpit:1025'

Passing the -i along to the Symfony Mailer is quite difficult in our setup. But the code and discussion in the Symfony issues only confuses me more.
If -i is used there, then Symfony Mailer will not add the dots. But that -i is then passed along to sendmail too, isn't it? So sendmail would (partially) ignore periods too. Seems to me that no one understands how this should work. Symfony Mailer shouldn't bother with this at all and let sendmail handle it.

That's outside the scope of this issue though.

<!-- gh-comment-id:2912414883 --> @AlexHaan-i commented on GitHub (May 27, 2025): Thank you for your response. I should have searched for 'dots'... That `sendmail -i` parameter is quite confusing; https://linux.die.net/man/8/sendmail.sendmail : > Ignore dots alone on lines by themselves in incoming messages. This should be set if you are reading data from a file. My message doesn't have an alone dot though. But setting up PHP(.ini), for our Docker setup as follows does indeed strip that dot; ``` sendmail_path = '(echo "X-Tags: somecustomtaghere"; cat -) | /usr/local/bin/mailpit sendmail -t -i -S mailpit:1025' ``` ---- Passing the `-i` along to the Symfony Mailer is quite difficult in our setup. But the code and discussion in the Symfony issues only confuses me more. If `-i` is used there, then Symfony Mailer will not add the dots. But that `-i` is then passed along to `sendmail` too, isn't it? So `sendmail` would (partially) ignore periods too. Seems to me that no one understands how this should work. Symfony Mailer shouldn't bother with this at all and let `sendmail` handle it. That's outside the scope of this issue though.
Author
Owner

@axllent commented on GitHub (May 27, 2025):

The-i flag in Mailpit's sendmail implementation, like many other sendmail clients, is a valid flag, however it is just ignored. It is simply there for backwards compatibility and instances like this.

Symfony mailer supports far more than just sendmail, it also supports things like direct SMTP transactions.

<!-- gh-comment-id:2913643410 --> @axllent commented on GitHub (May 27, 2025): The`-i` flag in Mailpit's sendmail implementation, like many other sendmail clients, is a valid flag, however it is just ignored. It is simply there for backwards compatibility and instances like this. Symfony mailer supports far more than just sendmail, it also supports things like direct SMTP transactions.
Author
Owner

@axllent commented on GitHub (May 27, 2025):

It's just worth mentioning that there are many, many sendmail variations, and they are all very similar but not quite the same. Then you have symfony mail which does or doesn't insert extra dots based solely on whether that flag exists in the sendmail argument. It is what it is though, I can't change that.

The bottom line is this is not a bug in Mailpit or Mailpit's sendmail, it is a feature of symfony's mailer lib, and this is the documented way to avoid that.

<!-- gh-comment-id:2913725237 --> @axllent commented on GitHub (May 27, 2025): It's just worth mentioning that there are many, many sendmail variations, and they are all very similar but not quite the same. Then you have symfony mail which does or doesn't insert extra dots based solely on whether that flag exists in the sendmail argument. It is what it is though, I can't change that. The bottom line is this is not a bug in Mailpit or Mailpit's sendmail, it is a feature of symfony's mailer lib, and this is the documented way to avoid that.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/mailpit#327
No description provided.