You’re not wrong. It’s overkill in a way.
But many static websites are hosted on platforms where users can’t simply execute scripts (GitHub pages, for example), so such script would need to live elsewhere. And wrapped inside a Docker container is the most versatile way.
How so? You need a VPN or container platform that allows outbound email, which is increasingly hard to find, or you need to do local delivery and also host an IMAP or similar server on the site.
Or you can stick an email script on a hosting site like Nearly Free Speech that just provides a scripting host, pay a fraction of the cost of hosting a full VM (it would cost under 50 cents a month to simple contact page that forwards to email on NFS, not sure about other providers).
I can easily find web hosting providers that allow scripts and outbound email (the first one I looked at did), the first few container- and VM-hosting platforms that I looked at didn’t.
While you’re going to both need something that provides outgoing email, and something that runs containers, they don’t need to be the same platform. You can run the container on any PaaS, and use it with any SMTP server.
And for SMTP, there’s no shortage of free providers (e.g. gmail)
So yes, this is fairly easy to set up for free; I’d reckon it’s simpler than subscribing for cheap hosting and wiring up custom scripts. That said, I too would rather bundle such functionality along with the rest of the website, if possible. But this is catering to a rather specific use case where that is not a realistic scenario (either because they don’t know how, or their platform doesn’t allow it) - I will try to make that use case more clear in the README!
If I have to go to the trouble of finding a second host to run the Docker container or whatever, why wouldn’t I just host my entire website there to start with?
I’m going to go out on a limb here and suggest that AWS probably blocks arbitrary outbound SMTP in Lambda. I’m sure you can use their Simple Email Service… but that’s not what this container does.
Oh, you certainly could host your entire website there, and I certainly wouldn’t recommend this for any more advanced project either - I would also rather consolidate code on 1 platform.
That said, there are plenty of simple websites where “just hosting all of it in one place” doesn’t work. Either because it uses platforms/generators that don’t support/allow that (e.g. GitHub pages), or because the devs don’t know how (e.g. many who start dabbling with HTML will not know how to build a simple script that runs with the scripting languages available, or how to install others)
I concede that this is certainly not a recommended solution in many cases - it’s a stopgap for some rather specific (albeit not uncommon) cases, and I should probably make those more clear in the README!
I guess I should have pointed out that it was http://hostedformmail.com/cpi-bin/formmail.pl or whatever, with some POST parameter “client_id.” That probably would have been helpful context.
While it’s possible to include these variables in the data your form will submit, it makes sense to hard-code (sic) some of these in the web service, to prevent others from being able to (ab)use your service.
Isn’t this an open relay until you configure it? (“hard-code” in an environment variable, if you will)
It would be a lot better for the internet if this was secure by default. I’m getting enough spam from *.outbound.protection.outlook.com as it is.
Correct. However locking it down by default may eliminate some options.
I can imagine cases where one would want to accept requests from multiple (or any) source(s), as long as all mail ends up at one specific recipient. While it would technically still be open to abuse, there would be no purpose and it would easily be spotted.
OTOH, I can imagine cases where one may want more flexibility WRT recipients and not lock that down too strictly, as long as requests all come from certain sources (although ALLOW_ORIGIN alone doesn’t necessarily suffice)
But your point still stands, and I think there are ways to slightly improve things without losing too much flexibility, e.g. by allowing users to configure a whitelist of recipients, or implementing some sort of recipient verification. I may look into that shortly - thanks for bringing this up!
I can imagine cases where one would want to accept requests from multiple (or any) source(s), as long as all mail ends up at one specific recipient.
That would be fine; you’re only sending spam to the single recipient. You’re not sending spam to other people on the internet. The problem is allowing arbitrary recipients.
I’m not saying that you should not support this feature (though I’d be hard pressed to find a valid use case), what I’m saying is that it should be secure by default, aka opt-in.
One way to implement this, is to make the application refuse if the environment variable is not set, but by setting it to * it can function as an open relay. Or even have a separate OPEN_RELAY environment variable. That way, nobody runs an open relay by accident, but you still support your use case.
Many people who install an application will do the absolute minimum of configuration, if it starts and it works they’re done. It’s your job as developer to make sure that deployment is secure.
Yeah, you’re right. There’s no reason it shouldn’t be a conscious decision and be required to be set (even if to *). Same for DSN, actually, which would likely only lead to people exposing their SMTP credentials… Making those changes now.
Back in my day, we used
cgi-bin/formmail.cgi, written in Perl, and calling out to the local MTA to do this. Docker seems much more complicated.You’re not wrong. It’s overkill in a way. But many static websites are hosted on platforms where users can’t simply execute scripts (GitHub pages, for example), so such script would need to live elsewhere. And wrapped inside a Docker container is the most versatile way.
How so? You need a VPN or container platform that allows outbound email, which is increasingly hard to find, or you need to do local delivery and also host an IMAP or similar server on the site.
Or you can stick an email script on a hosting site like Nearly Free Speech that just provides a scripting host, pay a fraction of the cost of hosting a full VM (it would cost under 50 cents a month to simple contact page that forwards to email on NFS, not sure about other providers).
I can easily find web hosting providers that allow scripts and outbound email (the first one I looked at did), the first few container- and VM-hosting platforms that I looked at didn’t.
While you’re going to both need something that provides outgoing email, and something that runs containers, they don’t need to be the same platform. You can run the container on any PaaS, and use it with any SMTP server.
Both of those can easily be found for free.
While Heroku stopped providing free tiers, there are still plenty of others (e.g. https://github.com/matthiasmullie/post-to-email/blob/main/instructions/1-paas.md)
And for SMTP, there’s no shortage of free providers (e.g. gmail)
So yes, this is fairly easy to set up for free; I’d reckon it’s simpler than subscribing for cheap hosting and wiring up custom scripts. That said, I too would rather bundle such functionality along with the rest of the website, if possible. But this is catering to a rather specific use case where that is not a realistic scenario (either because they don’t know how, or their platform doesn’t allow it) - I will try to make that use case more clear in the README!
If I have to go to the trouble of finding a second host to run the Docker container or whatever, why wouldn’t I just host my entire website there to start with?
You can run a Docker container in a AWS Lambda for free under a certain usage limit.
I’m going to go out on a limb here and suggest that AWS probably blocks arbitrary outbound SMTP in Lambda. I’m sure you can use their Simple Email Service… but that’s not what this container does.
you can ask for removing the block of outgoing port 25
SES provide an SMTP interface
Oh, you certainly could host your entire website there, and I certainly wouldn’t recommend this for any more advanced project either - I would also rather consolidate code on 1 platform.
That said, there are plenty of simple websites where “just hosting all of it in one place” doesn’t work. Either because it uses platforms/generators that don’t support/allow that (e.g. GitHub pages), or because the devs don’t know how (e.g. many who start dabbling with HTML will not know how to build a simple script that runs with the scripting languages available, or how to install others)
I concede that this is certainly not a recommended solution in many cases - it’s a stopgap for some rather specific (albeit not uncommon) cases, and I should probably make those more clear in the README!
I guess I should have pointed out that it was
http://hostedformmail.com/cpi-bin/formmail.plor whatever, with some POST parameter “client_id.” That probably would have been helpful context.Isn’t this an open relay until you configure it? (“hard-code” in an environment variable, if you will)
It would be a lot better for the internet if this was secure by default. I’m getting enough spam from *.outbound.protection.outlook.com as it is.
Correct. However locking it down by default may eliminate some options.
I can imagine cases where one would want to accept requests from multiple (or any) source(s), as long as all mail ends up at one specific recipient. While it would technically still be open to abuse, there would be no purpose and it would easily be spotted.
OTOH, I can imagine cases where one may want more flexibility WRT recipients and not lock that down too strictly, as long as requests all come from certain sources (although
ALLOW_ORIGINalone doesn’t necessarily suffice)But your point still stands, and I think there are ways to slightly improve things without losing too much flexibility, e.g. by allowing users to configure a whitelist of recipients, or implementing some sort of recipient verification. I may look into that shortly - thanks for bringing this up!
That would be fine; you’re only sending spam to the single recipient. You’re not sending spam to other people on the internet. The problem is allowing arbitrary recipients.
I’m not saying that you should not support this feature (though I’d be hard pressed to find a valid use case), what I’m saying is that it should be secure by default, aka opt-in.
One way to implement this, is to make the application refuse if the environment variable is not set, but by setting it to
*it can function as an open relay. Or even have a separate OPEN_RELAY environment variable. That way, nobody runs an open relay by accident, but you still support your use case.Many people who install an application will do the absolute minimum of configuration, if it starts and it works they’re done. It’s your job as developer to make sure that deployment is secure.
Yeah, you’re right. There’s no reason it shouldn’t be a conscious decision and be required to be set (even if to
*). Same for DSN, actually, which would likely only lead to people exposing their SMTP credentials… Making those changes now.Done!
I prefer a trivial dumping sh cgi and a private atom feed to subscribe. https://codeberg.org/mro/form2xml makes the dumps browser-readable.