11–20 of 75 posts
Earlier quoted context omitted.
I haven't tried it myself (and won't) but given this section "Passing Secrets" in the README [1] I dont think its authless. [1] https://github.com/dthree/mailit/blob/master/readme.md#passi...
Those secrets are for Mailit itself to connect and authenticate against the email server.
Earlier quoted context omitted.
Those secrets are for Mailit itself to connect and authenticate against the email server.
Ah you're right. So this is even worse than I thought..
It migt be just me, but I honestly don't understand why people would use an HTTP API to send mail. SMTP really is a very simple protocol, that's matured for decades now. Also it is fully specified by RFCs. I can see why mail services that provide templating (eg Mandrill) have special APIs, they offer something different from sending regular emails. This specific REST API seems more like a standin for sendmail, which…
It migt be just me, but I honestly don't understand why people would use an HTTP API to send mail. SMTP really is a very simple protocol, that's matured for decades now. Also it is fully specified by RFCs. I can see why mail services that provide templating (eg Mandrill) have special APIs, they offer something different from sending regular emails. This specific REST API seems more like a standin for sendmail, which…
I've looked at setting up sendmail as a "LAMP guy" and I said nope nope nope, just use mailgun.
Using an HTTP API for this is a massive overkill.
* I'm aware using utf-8 like this may confuse older clients but I didn't have problem with anything relatively modern I tested the receiving on.
It migt be just me, but I honestly don't understand why people would use an HTTP API to send mail. SMTP really is a very simple protocol, that's matured for decades now. Also it is fully specified by RFCs. I can see why mail services that provide templating (eg Mandrill) have special APIs, they offer something different from sending regular emails. This specific REST API seems more like a standin for sendmail, which…
It migt be just me, but I honestly don't understand why people would use an HTTP API to send mail. SMTP really is a very simple protocol, that's matured for decades now. Also it is fully specified by RFCs. I can see why mail services that provide templating (eg Mandrill) have special APIs, they offer something different from sending regular emails. This specific REST API seems more like a standin for sendmail, which…
I've looked at setting up sendmail as a "LAMP guy" and I said nope nope nope, just use mailgun.
Creating the relay is the hard part of any mail service because even SMTP aside, you need to set DNS entries on your FROM domain to authorise your SMTP relay's IP (otherwise spam filters will just block your email). And if it's regular commercial mailshots then you'd need to register with one of the trusted services (which isn't free) and have all sorts of controls like rate limiting in place - again so you don't just get rejected as spam.
Honestly, I would welcome a complete ground up re-implementation of email - SMTP, POP/IMAP and all. The "very simple protocol, that's matured for decades now" is really just a mess of different protocols - different authentication models, different encryption methods, etc and all operating without a standard format for error handling. Plus all of the additional bloat bolted on to handle the swell of abuse that the email "network" has had to endure. There's nothing simple about email any more.
However going back to the topic: the unfortunate thing about this REST API is it seeks to solve the least complicated part of the whole SMTP stack.
Earlier quoted context omitted.
I've looked at setting up sendmail as a "LAMP guy" and I said nope nope nope, just use mailgun.
Sendmail is everything but simple. The question was SMTP in general, which indeed is an extremely simple protocol. Here, this is how you send a plain text* mail in python: https://petermolnar.net/not-mime-email-python-3/ Using an HTTP API for this is a massive overkill. * I'm aware using utf-8 like this may confuse older clients but I didn't have problem with anything relatively modern I tested the receiving on.
I wouldn't call it massive overkill. REST is extremely simple as well. You have to make an request anyways so it's just a question of preference how you connect to that the email sending service.
Earlier quoted context omitted.
Sendmail is everything but simple. The question was SMTP in general, which indeed is an extremely simple protocol. Here, this is how you send a plain text* mail in python: https://petermolnar.net/not-mime-email-python-3/ Using an HTTP API for this is a massive overkill. * I'm aware using utf-8 like this may confuse older clients but I didn't have problem with anything relatively modern I tested the receiving on.
Sending is not the tricky part, implementing it right is probably another story. I wouldn't call it massive overkill. REST is extremely simple as well. You have to make an request anyways so it's just a question of preference how you connect to that the email sending service.
You're running a web server to emulate telnet. It's a massive overkill.
Earlier quoted context omitted.
Sendmail is everything but simple. The question was SMTP in general, which indeed is an extremely simple protocol. Here, this is how you send a plain text* mail in python: https://petermolnar.net/not-mime-email-python-3/ Using an HTTP API for this is a massive overkill. * I'm aware using utf-8 like this may confuse older clients but I didn't have problem with anything relatively modern I tested the receiving on.
Sending is not the tricky part, implementing it right is probably another story. I wouldn't call it massive overkill. REST is extremely simple as well. You have to make an request anyways so it's just a question of preference how you connect to that the email sending service.
Do you implement your own HTTP communication every time you need it or do you use a library?
Just as for HTTP there are many good libraries for SMTP communication that you can easily use. No need to roll your own.
Earlier quoted context omitted.
I've looked at setting up sendmail as a "LAMP guy" and I said nope nope nope, just use mailgun.
You still need to set up the SMTP server with this solution. Creating the relay is the hard part of any mail service because even SMTP aside, you need to set DNS entries on your FROM domain to authorise your SMTP relay's IP (otherwise spam filters will just block your email). And if it's regular commercial mailshots then you'd need to register with one of the trusted services (which isn't free) and have all sorts of…
I'd welcome that too, it's kinda sad nobody succeeded with "email 2.0", sure we have lots of attempts but I can't recall any major players. The best solutions to "fix email" were companies that advocated to not use email and use their closed platform.
What I can think of would be cool is something XMPP based with email fallback.