-
-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does not work with Alpine Linux's sendmail #87
Comments
Thanks for all the testing and narrowing down the issue @sjinks. I believe the big difference here between MailHog and Mailpit is that the SMTPD server within MailHog appears to be a custom implementation which maybe isn't as RFC-compliant as it says it is (and, according to the screenshots in the PR you linked from, makes a real mess of the headers / body). Mailpit uses mhale/smtpd which complies to the RFC standards, and will reject non-compliant emails. The RFC standards state that There are a couple of work-arounds (eg: There also appears to be a new backwards-compatibility PHP INI configuration - but I couldn't get that working so that may only be PHP 8.2 (or still unreleased?), I don't know. Either way though, I do not think the issue here is in Mailpit's SMTPD, but in the default MTA used in Alpine (which is actually busybox's sendmail implementation) - or in Alpine itself (this goes beyong my understanding unfortunately). Mailpit is simply following the RFC, and doing what it should - the email being delivered via sendmail is not compliant, so it is rejected. If I was to create a work-around within Mailpit, it would mean that Mailpit would allow non-compliant emails to be delivered, and by definition defy the point of an SMTP testing tool. I do not think that is a good solution at all. So I'm not sure "where to" from here unfortunately, but I feel the solution lies in the sendmail version used. There are alternative sendmail implementations available in Alpine. I use msmtp in production (for Alpine docker implementations), and configure PHP to use to |
Hmmm… However, it still works with Postfix:
Yes, you were right, I was able to confirm that with nc -l -p 10025 -s 127.0.0.1 -e nc -v -o transaction2.txt 127.0.0.1:1025 and cat data.txt | /usr/sbin/sendmail -v -S 127.0.0.1:10025 -t (where
Great, thanks! I was able to send a test email with this: php -d "sendmail_path=/usr/bin/msmtp --host=127.0.0.1 --port=1025 -t --auto-from" -r 'mail("[email protected]", "Subject", "Body");' Closing then, as this is not a bug :-) Thank you! |
Thanks for the confirmation either way. Interesting that it works with postfix, though I suspect that is a "feature" in postfix to fix this very issue (work-around). Then again, even if postfix accepts the mail, it doesn't mean it is strictly valid, and there's no assurance other mail servers will accept it. I'm no C expert, but I found send_r_n() which is referenced several times in sendmail.c. It sends every line with a trailing Glad you got it working though! |
Steps to reproduce:
mailpit
container:docker run -it --rm axllent/mailpit
docker exec
into the container and run:Expected result: email is queued
Actual result:
In mailpit logs, I see:
RRO[2023/04/10 10:51:02] error parsing message: malformed MIME header line: To: [email protected]
My debugging showed that
mailpit
does not handle<CR>
: the lines above with the leading'
actually contain the<CR>
character:is
To confirm my finding, I modified the
sendmail_path
setting:Now it works as expected:
However, I think that
mailpit
should handle the<CR>
character in the mail body (MailHog does).Unfortunately, I don't know Go good enough to submit a PR, sorry :-(
The text was updated successfully, but these errors were encountered: