mirror of
https://github.com/axllent/mailpit.git
synced 2026-04-26 00:35:51 +03:00
[GH-ISSUE #501] No support for RFC5321 4.5.2 Transparancy causing double periods #327
Labels
No labels
awaiting feedback
bug
docker
documentation
enhancement
github_actions
invalid
pull-request
question
stale
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mailpit#327
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
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.
@axllent commented on GitHub (May 27, 2025):
Hi. To help me narrow down where you are seeing this issue:
The received message source:
It appears new lines within the body starting with a
.are in fact "stripped", so where is the issue here?@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:
The resulting "HTML source" is then:
@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.
@axllent commented on GitHub (May 27, 2025):
Ahh yes, symfony, see https://github.com/symfony/symfony/issues/50875
You have to include the
-iin the mailer config. The symfony mailer has a really basic system where it will add the extra dot if there's no-iin the command.@axllent commented on GitHub (May 27, 2025):
Also see #350.
@AlexHaan-i commented on GitHub (May 27, 2025):
Thank you for your response. I should have searched for 'dots'...
That
sendmail -iparameter is quite confusing; https://linux.die.net/man/8/sendmail.sendmail :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;
Passing the
-ialong to the Symfony Mailer is quite difficult in our setup. But the code and discussion in the Symfony issues only confuses me more.If
-iis used there, then Symfony Mailer will not add the dots. But that-iis then passed along tosendmailtoo, isn't it? Sosendmailwould (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 letsendmailhandle it.That's outside the scope of this issue though.
@axllent commented on GitHub (May 27, 2025):
The
-iflag 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.
@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.