mirror of
https://github.com/axllent/mailpit.git
synced 2026-04-26 00:35:51 +03:00
[GH-ISSUE #172] Beginner guidance #116
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#116
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 @ulken on GitHub (Sep 27, 2023).
Original GitHub issue: https://github.com/axllent/mailpit/issues/172
First of all, what a great tool you've developed. Simple, lightweight SMTP + API = ❤️
Being a n00b, both with this tool and in the SMTP world in general, I do have a few questions I could need a hand with:
My current attempt is to pass an empty auth file to SMTP auth file env var/flag. But it also requires me to allow insecure auth. Is that the way to go? Feels a little odd.
I read something similar using the relay functionality, but I don't think that's what I'm after here, unless I'm missing something (which is totally possible).
Thank you for bearing with me 😊
@axllent commented on GitHub (Sep 27, 2023):
Please see my comments below @ulken
You're welcome!
By readonly I suspect you mean "receive only" - in that Mailpit can receive emails, but cannot send them? If so, then yes most definitely, this is actually the default.
A SMTP authentication file is only needed if you require authentication to send email to Mailpit. I do not fully understand what your expectation is with your setup - whether it is you sending email to Mailpit, or whether it is supposed to be "open to the internet" to receive emails from anyone. Could you please explain?
No, this is not how it works. Mailpit is designed to accept any/all email sent to it. There is no filtering of any sort, only "tagging" (if set) based on "filters" you can set. If SMTP authentication is set, then that is required to send to Mailpit, but even with authentication it will accept all mail (provided it is a valid email of course).
I don't think that is what you are wanting, though difficult to know without a clear explanation of what it is you are trying to achieve. Again, relay (automatically sending messages onto their intended destination) is optional, and by default off.
Passwords can be stored in an encrypted manner, however let's not get into that right now until I understand exactly what it is you are wanting to achieve here.
Mailpit is designed an an SMTP testing tool. Common use cases are application/website developers who need to test their application's email sending capabilities - without spamming users. Mailpit it used as the SMTP server and "swallows" the emails without actually sending them on. The developer can then view those emails and ensure they are formatted correctly and contain the correct information.
It sounds to me however that you are wanting to set it up as a receiving mail server (ie: actual emails get delivered to it from other SMTP servers). I need clarification though.
No problem :)
@ulken commented on GitHub (Sep 27, 2023):
Thank you for your swift reply. Although I'm just getting started with Maillpit, I must say I've yet to meet a more kind, attentive and open-minded open source developer than yourself. Hope you're not wearing yourself out in the process.
I apologize for being unclear to you. Let's take a different approach and let me describe my use case:
We have had problems with alert notifications not being sent from Grafana more than once and decided to take several measures to get on top of it. The reasons have varied: changing mail provider and forgetting to update the SMTP credentials in Grafana, upgrading Grafana and forgetting to adjust the custom notification template etc. Mistakes happen, but we should be aware as soon as they happen. Until now, it could be weeks or even months before we realize it's not working. At times, customers would inform us 🤦
Apart from adding monitoring to logs, we want to add E2E monitoring.
My idea is to have a constantly firing (alerting) alert in Grafana, sending out reminders every X minutes. The email would be sent to an address accepted by Mailpit, running in a Docker container, on a VM in Azure.
Another script (Azure Function) would run every Y minutes to list messages in the mailbox and verify we are receiving alerts as expected. Otherwise notify responsible parties.
So yes, from Mailpit's point of view, I only want to receive emails (and preferably only ones I would allow to leave out spam).
Does that give you enough insight into the problem I want to solve?
I've tried multiple other approaches: Microsoft Graph API + Office365, Gmail API, WildDuck, but they've either been too complicated or required permissions I do not have and don't want to depend on.
@ulken commented on GitHub (Sep 27, 2023):
I guess I can tag messages I'm interested in and filter out those in the verifying script. I'm just afraid all kinds of spam would end up in and fill the inbox. I had one spam email sent within the first 10 minutes of being "live".
@ulken commented on GitHub (Sep 27, 2023):
Another newbie question: which port is actually used when sending/receiving the mails? 25? 465? 587? Right now I've bound them all to 1025 and of course I can find out by trial and error. Just curious if you have a short answer.
@ulken commented on GitHub (Sep 27, 2023):
And regarding authentication I still want that for the web UI and API, so I suppose the question around encryption of passwords still apply.
@axllent commented on GitHub (Sep 27, 2023):
Thanks for the kind words :)
From what I understand - you want Mailpit to effectively catch only emails sent by Grafana, ie: the online Grafana "webmail" of sorts? If that is the case (keep in mind I'm not familiar with Grafana's setup), I'm sure you can configure Grafana with which SMTP server to use?
So what you could do is run a Mailpit docker instance whereby port 1025 (the default Mailpit SMTP port) is only accessible to the Grafana server (firewall, or if it's running on the same server via Docker) - then you just set up Grafana to use Mailpit as its SMTP server. That would sort out the email sending and "receiving" - they would all go to Mailpit. You wouldn't even need to use TSL and/or SMTP authentication - assuming the Grafana server is the only IP with access to Mailpit's port 1025.
Then comes the matter of the web UI - ie: your access to Mailpit. This could have restricted access (username/password) using the Basic Authentication method - the credentials file would be as simple as a text file in
username:passwordformat (one per line), or those passwords could be encrypted in that text file (that link explains a bit more, but the htpasswd format is quite popular). There are even online websites that can generate those for you such as https://htpasswd.org/ (use the Apache MD5 one), so you end up with something likeusername:$apr1$ZpnLrpTc$wGOXX6qSEv91HM0Jm1n7H/. This would restrict the web UI and API with Basic Authentication. As an added measure, you could use set the web UI up with HTTPS (or via a proxy server running Nginx or Apache etc), however there are several approaches to that are too long to explain now, and I don't know what you do or don't understand regarding sysadmin. Seeing as you already set up Grafana and are referring to docker containers I suspect a fair bit.Does that make sense?
@ulken commented on GitHub (Sep 27, 2023):
The first part is correct and yes, you can configure which SMTP server to use (which I hinted at naming the type of problems we've had). But I don't think that's the way to go here. We still want "regular" (as in not for monitoring purposes) emails to go through our regular SMTP server. Plus, we want to test as much as possible of the production chain. I.e. if the SMTP server goes down or similar, we would want to be notified by that as well. In short: if alert emails are not delivered as expected (for whatever reason), we want to know.
Yeah, that sounds good in theory and I did consider something similar, but as I mentioned above, we would rather monitor the setup as used in production, in order to catch as many potential issues as possible.
That's all fine and dandy. I've already got that far on my own (using the docs 👍 ), thank you. Although I went with Bcrypt. I still don't understand how encrypting the password adds any extra security apart from making it seemingly more random and obscure.
If the password can be decrypted without providing any key and/or salt etc. to the application, I can't fathom how that could possibly work in matters of security.
I'm already using Caddy as a reverse proxy here, so TLS is already taken care of. No need to worry about that within the Docker network.
@ulken commented on GitHub (Sep 27, 2023):
And if you do "accept" my desired solution, (spam) filtering and ports used are still open questions.
@axllent commented on GitHub (Sep 27, 2023):
I'll need to get back to you in about 18 hours or so, bed time then work tomorrow 👍 In the meantime, does Gratama send out emails to different people, and you just want to catch one of those email addresses?
@ulken commented on GitHub (Sep 27, 2023):
No rush. Take your time. Thank you very much for assisting and I wish you a good night's sleep 😴
@axllent commented on GitHub (Sep 27, 2023):
Sorry, I just edited my previous comment with a question 😂
@ulken commented on GitHub (Sep 27, 2023):
Gratama is a cool name 😎
But yes, very much so. We use their dashboards and alerting engine in combination with IoT devices monitoring water distribution systems. So we have hundreds or even thousands of different email addresses it's sent to.
The one in question here is special, but set up as a normal alert.
@ulken commented on GitHub (Sep 27, 2023):
To clarify, those are all separate alerts, with different recipients. So this alert mail is only sent to one specific address.
@axllent commented on GitHub (Sep 27, 2023):
Sorry, that was a typo / autocorrect / bad eyesight 😬 Considering that Grafana send to many different email addresses, we can't use Mailpit as the SMTP server to send directly to because it will intercept all emails and nothing will get out.
The only potential solution I can think of is that Mailpit would act like a regular SMTP server (with port 25 on the host mapped to 1025 in the docker container). The email address you wish to receive would need to resolve to that Mailpit server so that external mail servers try to deliver directly to it. You may need to set the MX records of that subdomain if using an existing domain that normally points elsewhere. The downside of this is that your Mailpit server is then open to the world, so spammers will definitely try to use it to relay spam, and Mailpit will just ingest anything sent to it. If your regular SMTP server (I don't know which one you use) has a dedicated IP address(es), you could firewall it off from everything except for that/those.
This solution should work, but still opens you up to the potential that the default SMTP server's IP changes and thus is firewalls off.
@ulken commented on GitHub (Sep 28, 2023):
That wasn't 18 hours 😉 Did you cheat at work? 😬
First, I should probably have clarified from the start that I already got the setup working. My initial questions was more towards best practices.
That's exactly what I'm doing and yes, I had to add an MX record. Good tip on firewalling IP addresses 👍 I had thought of it, but now I actually did it. We're using Office365/Outlook, so their IP address ranges should be pretty stable. Otherwise, if all works as planned, we'll be notified and can update accordingly.
Thank you for verifying the port. Now my only remaining question mark is around the practicality around password encryption. Then I'll be out of your way (I think 😛).
@axllent commented on GitHub (Sep 28, 2023):
I had actually replied before work - trying to get through GitHub issues faster than they are building up (and failing it seems lol) :) It sounds like you have it sorted, and limiting the IP addresses will sort your potential spam issue (unless that domain is being used already, in which case you should use a subdomain with MX records or something)!
Just for clarity, you do not need (or should have) passwords set for the SMTP server, else the remote server(s) won't be able to deliver mail. So with regards to the password encryption, those password hashing are almost all one-way hashing (ie: cannot be decoded, only compared with via "CPU expensive" lookups), and are similar to Linux system password hashing, or in fact any good password system these days. You can see a list of the supported hashing algorithms. Whilst plain text is supported (
user:password), so are all those other algorithms too for the more security-conscious. I won't explain how each work, in fact I don't even want to know (it's really technical, and whilst similar, they all are different) - but they are (almost?) all salted. You can use any of those supported ones, so if you are concerned then just look up each one and decide on whatever suits you best.Lastly - don't forget - by default Mailpit will loose all emails when restarted unless you have specified a database file to use. Also, it will only keep the latest 500 messages unless otherwise specified (see the runtime options).
I hope this answers all your questions?
@ulken commented on GitHub (Sep 28, 2023):
Yep, using a subdomain, thanks 👍
Yes, I already got the SMTP authentication sorted from your previous reply. I'm referring to the UI/API now.
Ohhhh, now (I think) I understand. one-way hashing was the missing key (he he) for me. I thought they were being decrypted on the other end and then the setup made no sense. Now that makes perfect sense, thank you very much for your patience!
Yes, I'm aware, thank you. Already using a db file and 500 is more than enough. I'm just interested in the latest emails.
For the time being, yes ✅