Thanks all for all of the suggestions!

For the improvements, I will try get all of them done by tomorrow; they've all been really good!

For those of you suggesting alternatives:

* If you're suggesting them as a sort of 'BTW you can do this as well', then awesome

* If you're questioning 'why did I re-invent the wheel', as I've said in other comments:

a) Sending mail directly from a machine can be troublesome (lack of ports open, lack of SPF record for sending domain (since it maybe a workstation) etc.)

b) I've struggled to find an alternative method (since my original use for this was few and fare between) that I could actually remember.. often looking up how to send mail through curl for example meant reading multiple websites each time and time spent to get it working wasn't worth it, whereas I've never had problems remembering 'curl curlmail.co/email' :)

Thanks for all the feedback so far and, as with any quick side-project hack, if a single person in a real situation ends up using it and finds it useful, then its served it's purpose in my opinion!

Thanks

Simple and useful. Excellent work! If you feel the need to mitigate potential abuse, you could first send a verification email for any new recipient-email (or sender-ip / email combo) -- requiring active opt-in from the recipient. Personally I wouldn't bother unless it becomes an issue :)

Given that the 'activation' email is not _that_ much different that a notification itself... I guess the service could be activation-less (with maybe a low rate limit) without clicking an activation link on emails.

Once the user has activated, then they can include content and customisable subject (which at the moment anyone can do).

That sounds really good and hopefully wouldn't take away from the original simplicity.

Thanks, that's an awesome suggestion!

And forgot to mention, I completely agree about sender-ip/email combination for verification :)

It seems that I can unsubscribe everyone like this:

    curl "https://www.curlmail.co/unsubscribe/EMAIL"

This may or may not be considered as an attack vector. If I know that someone is using the service, I can “troll” them by unsubscribing their email and they will stop receiving the alerts. A solution to this would be to include a verification code in the “unsubscribe” link that you are sending with the alert. Unsubscribe only if the verification code exists and matches the one associated with the email.

It's funny you should mention that... I made a commit a couple of months ago that I never released: 6e898a9db280 matthew Add tokens to un-subsribe Sep 18 2018, 2:09 PM

Rolled out, so should be fixed :)

FWIW, if you use Amazon SES, it costs $1 to send 10,000 e-mails a month, with a regular mail client. If you use EC2 or EB, you get 62,000 sends free. So you could use echo/cat/sendmail with an SES account to handle a crapload of e-mail notifications for practically nothing.

https://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-e...

Which is what we do at one of my startups... our monthly AWS bill is $5.

cURL speaks SMTP natively, so you could also send to a local SMTP server, or to the SMTP server in your email provider's MX records. (For emailing myself, I've never had much trouble sending mail directly to Gmail's MX records)

    curl --mail-from "you@gmail.com" --mail-rcpt "you@gmail.com"  --ssl-reqd --url smtp://aspmx3.googlemail.com -T <(echo -e 'From: you@gmail.com\nTo: you@gmail.com\nSubject: Curl Test\n\nHello');

I'm stealing that for .bash_profile! It get's a spam marking right away, but useful nonetheless!

This is going to get abused so fast

There is rate limiting on both sender IP, recipient email and recipient domain. As well as unsubscribing. Will improve this if it does start getting abused

> send to multiple addresses

So this will need to be limited to just several addresses?

> rate limiting on... recipient domain

Including gmail.com and outlook.com?

I'd guess that the simplest option would be to require some sort of registration and requiring an "API token" with every request. Not as clean and easy-peasy, but far more practical for moderation purposes.

Alternatively, a self-hosted version of the same would solve these problems. But if you are planning on turning this into a $ service at some point, that's probably not going to work because of that.

>> send to multiple addresses

> So this will need to be limited to just several addresses? If this is in reference to rate limiting, each address is limited seperately, so if you send a message to 4 addresses and one's over the limit, it will fail and the rest willt work.

If you mean is there a limit to the number fo addresses per request, then there actually isn't and that's a VERY good point, so thank you!

>> rate limiting on... recipient domain

> Including gmail.com and outlook.com?

Yeh, the limit per domain is pretty high (compared to per email address).

> I'd guess that the simplest option would be to require some sort of registration and requiring an "API token" with every request. Not as clean and easy-peasy, but far more practical for moderation purposes.

If you having to register, verify your account, get an API key etc, then it's getting on towards the complexity of other services, which is, both, exactly what I was trying to avoid and means this is a cut-down version of other services, which then makes it redundant :) It was mainly meant for sending a notification to yourself when a command completes to check email delivery and such, not high volumes of traffic.

I run a similar service (but for browser/mobile notifications instead of emails[1]) and take basically that approach. So far abuse hasn't been an issue with ~50k notifications sent.

[1] https://notify.run

A few comments:

* It would be wise to stick an `https://` in the example URLs.

* Starttls is not used when sending, which ought to be fixed.

* For anti-abuse purposes, you ought to include the caller's IP address in the headers somehow.

Hey, thanks for the feedback..

All really good suggestions and will get cracking on them tomorrow :)

Thanks!

Interesting idea, although I'm left wondering what's in it for the operator of this service? There doesn't appear to be any "about us" or information about what's happening with the data I pipe to this url.

agree. I imagine people using this to send logfiles and alerts (potentially containing info about infrastructure topology of a site or patch level and names of hosts). That sounds like a dangerous idea when it's unclear who operates the site, and why.

Hey - WRT what's in it for the maintainer.. I run this on some servers that run a bunch of other sites.. and this was just a tiny project that I created because I was running a bunch of stuff on some servers that only had access to the internet through a proxy. Some of the things I was trying to run took a long time (10+ hours). So I wanted to get an easy notification and found signing up for other services to be a pain (need card info etc, because they expect bulk delivery)

WRT putting sensitive info through it... I completely agree, I wouldn't advise this - at the same time, I'd never advise sending any sensitive info over any email (without using GPG). The reason for suggesting custom content was, if I had several commands going that would send notifications, I wanted an easy way to identify which one completed (even just sending a number or simple word so I could idenity if). The idea of piping to it was simply an idea of how I could expand it and suite other people's use-cases.

Hope this all makes sense.. so no mass data gathering etc, and, as I say, I wouldn't advise putting any sensitive info through it anyway :)

Cool, sorry didn’t mean to come across as negative. I’m always appreciative when people share solutions to problems they’ve had. Thanks for clearing up some of my questions.

Haha, don't worry, I didn't take it as negative. Just wanted to fully answer it, so my reasoning came across :)

I was looking for just this 2 days ago!

Have a server that does not have SMTP port open, and bothering IT to open it will take ages. All I needed was to send email alerts if certain batch jobs fail. or if disks get close to full. Poor man's monitoring.

curlmail works like a charm.

Will be happy to get you a couple of cups of coffee. Please add some way to send you $.

This is awesome, thanks for sharing it.

Before I add a third party service, I want to be reasonably sure it will stick around for a while.

But the first time some idiot sends an anonymous threat through curlmail, you'll realize you have better things to do than talk to attorneys and law enforcement, and curlmail will disappear.

I wish simple utilities like this could exist, but anonymous public services have to deal with inevitable idiots, or they won't exist for long.

> Before I add a third party service, I want to be reasonably sure it will stick around for a while.

Not entirely sure what you mean about 'add a third party service'

That said, (aside from thank you for the first bit :) ), the rest does pose a very interesting point. Not something I'd massviely considered.. spam is one thing (which rate limiting sort of solves). But not threats and such. As it stands, there are no logs, apart from those that you'd normally expect from a web server, so that probably isn't great from a legal aspect.

I guess possibly rejecting emails based on content, bad word list or similar. I _did_ implement a policy that banned IP addresses when a notification was unsubscribed from (since it was intended for the user to email themselves), but this obviously doesn't stop the initial email from being sent.

I will certainly think about this and try get something knocked up asap to try and counter this.

Thank you for your comment!

actually not having logs is a great thing for legal reasons. If you are in the USA you are not required to keep logs for a service like this so I would not keep logs if I were you so that you don't get tied up with legal issues. At worst they make you shut down your service.

Broken:

<html><body><h1>400 Bad request</h1> Your browser sent an invalid request. </body></html>

Hey! Sorry about that - I'll take a look to see what happened

Hey, since no one asked (as it's tradition :P), I'll bite.

Have you got any ideas about monetization? Are there any usage limits? How about unexpected things you learned while building this? An 'about' page would greatly help us learn more and appreciate the project. I personally love the idea, great work, and great project!

Thanks! Really appreciate this.. always righting tiny things here and there, but only few I feel at all condifent to post on here :P I certainly can write an bit about how/why I made it - Will send a link across when it's done. Around monetisation, don't think that I'd ever bother. The cost of running it is next to nothing and would rather spend time working on new projects than having to deal with advertising and all that

Should setup DKIM for better deliverability

Good point - the main reason I hadn't yet done this is because the whole thing is split into docker containers (static page, api and mail server) and couldn't decide the best way to put a certificate on it without moving to something like Vault.

Will certainly look into this further!

1.- What is this made with?

2.- The page source links to a manifest at:

    "https://curlmail.co/manifest.json"

which answers:

    "Invalid email address"

maybe it has to do with the way it handles emails

It's due to a misconfiguration on the load balancer, in which URIs should be passed to the backends. The front-end is completely static and the backend just serves the 'api', which is why you're seeing that :)

Thanks for pointing this out

Manifests is now fixed :)

Sorry, didn't answer your first question..

Static front-page was knocked-up by a friend (https://github.com/bencevans).

The API is in python and uses a postfix container for sending the mail and redis for storing data for rate-limiting and unsubscribing

Hm...

    echo "My message" | mail -s subject user@mail.com

I built this primarily for myself, the main advatages are:

* Avoiding getting junked/rejected due to:

   * Missing/invalid SPF record

   * What would the sending domain be, if not set could easily be rejected

   * From a dynamic IP

 * Port 25 may not be open (it wasn't for my case)

I set up my servers to use Google's SMTP, then proceed to use inbuilt tools. So only port 25 (or whatever the TLS equivalents) blocking is a problem

I've worked at multiple companies where we created something like this internally for email and text messages.

Curl an API and out it goes. It's trivial to setup for yourself.

How would you deal with spam? Who's paying for this?

As I said below, there's various forms of rate limiting and it's running on servers that are already hosting other sites, so just the cost of a domain

It may just be because I'm super tired but I'm struggling to see how this is different from an open SMTP relay.

Well. I was testing the service and unsubscribed myself by accident. Is there a method to subscribe again?

Now I feel bad.. really sorry, but there isn't at the moment!

It doesn’t support all characters typically allowed in an email, e.g., “+”

This is amazing!