8 ms·

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 de

• icebraining 9y ago
  Playing Devil's advocate: SMTP has some back-and-forth stateful chatter. With a custom HTTP API, you can authenticate and send an email in a single request. SMTP Pipelining can reduce this problem, but not all libraries support it (e.g. Python's smtplib).
  • mariusmg 9y ago
    >SMTP has some back-and-forth stateful chatter. So what ? Is not like you implement the SMTP protocol into your application to send emails. Any language under the sun has a SMTP implementation exposed as a library.
    • jsudhams 9y ago
      Another reason i would do is , i have only port 80/443 allowed outside my network. so using https api helps with that
      • Rjevski 9y ago
        Why is that? What security does it provide? This very project just demonstrated that you can send pretty much anything in HTTP(S) so any malware (I presume) you're trying to defeat can do the same.
        • ctrlrsf 9y ago
          Spam malware can scan IPs to find open SMTP ports to send spam so some ISPs and hosting providers lock down these ports to avoid getting their IPs blacklisted when a compromised host starts sending a bunch of spam through an open relay. I can see this being used to send email out from some restricted hosting providers.
    • icebraining 9y ago
      It's slower, which is important when you're trying to push a lot of emails. If you keep the TLS connection open, sending an HTTP request is very fast. Waiting for the roundtrips of that chatter reduces the throughput, especially on higher latency links.
      • bjpbakker 9y ago
        > If you keep the TLS connection open, sending an HTTP request is very fast. Waiting for the roundtrips of that chatter reduces the throughput, especially on higher latency links. I agree that for a high load of sending email it can be beneficial to use an intermediate service. IMO a local sendmail is still preferred, but I see your point. However, the Mailit service makes the client wait on the SMTP traffic too [1]. So with this particular service you now have to wait for both SMTP /and/ HTTP communication. Doesn't really speed thinks up :) [1] https://github.com/dthree/mailit/blob/master/src/routes.js#L119 https://github.com/dthree/mailit/blob/master/src/routes.js#L...
        • icebraining 9y ago
          However, the Mailit service makes the client wait on the SMTP traffic too [1]. So with this particular service you now have to wait for both SMTP /and/ HTTP communication. Doesn't really speed thinks up :) That depends, you could host the Mailit service in the same machine as the email server, which your application instances on other machines would call. This could be useful if you have multiple machines but only want to run a single email server.
      • joantune 9y ago
        We have configured at work an intermediate postfix for this effect, but it takes a bit to learn how to configure it So I can see the benefits of this approach
      • deleted 9y ago
        [deleted]
• kowdermeister 9y ago
  I've looked at setting up sendmail as a "LAMP guy" and I said nope nope nope, just use mailgun.
  • pmlnr 9y ago
    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/ 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.
    • kowdermeister 9y ago
      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.
      • pmlnr 9y ago
        > I wouldn't call it massive overkill. You're running a web server to emulate telnet. It's a massive overkill.
      • bjpbakker 9y ago
        > implementing it right is probably another story 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.
    • beaconstudios 9y ago
      nowadays you have the option of using postfix+dovecot, which for me at least seems to be a lot easier.
  • 9y ago
• z3t4 9y ago
  For example to make it possible for a static (client only) web app to send mail. Watch out for spammers though! It should be secure by default, because most people either don't care or don't know how to change the defaults!
• pmlnr 9y ago
  Gmail is IMAP and SMTP, and Google Talk is (or was) XMPP, all on port 80 in the same browser window. Others are more metaphorical. Twitter is IRC on port 80, although one primarily listens to users instead of channels — but listening to channels is still possible, if one uses a client that can follow hashtags, and the syntax is even the same. Dropbox is FTP on port 80. Reddit is Usenet on port 80. https://medium.com/@maradydd/on-port-80-d8d6d3443d9a https://medium.com/@maradydd/on-port-80-d8d6d3443d9a
• lugg 9y ago
  > SMTP really is a very simple protocol, that's matured for decades now. Also it is fully specified by RFCs. So simple and so mature it needs an RFC. I'll take the http API I can figure out in 10 seconds because I make API requests all day over some ancient tech I don't even want to begin to understand. Does that make me lazy and a shit developer? Probably. Do I care. Definitely not.
  • GordonS 9y ago
    Having an RFC hardly means it's not simple; it means it has a well-defined specification. Do you actually think HTTP isn't specified in an RFC?
• w458cmau 9y ago
  I want to send mails from embedded devices, similar to e.g. an ESP8266, with intermittent connectivity and a semi-stable power source. An HTTP API seems simpler for me to interface with than SMTP.
  • zAy0LfpBZLC8mAC 9y ago
    I can't comment on what seems simpler to you, but ... what does intermittent connectivity have to do with whether you transmit the email via SMTP or via HTTP?
    • bjpbakker 9y ago
      > what does intermittent connectivity have to do with whether you transmit the email via SMTP or via HTTP SMTP uses a stateful connection where HTTP is basically a single request/response. I.e. the device can close the HTTP connection after a single roundtrip where SMTP requires waiting for server responses after commands and then continuing the request. Not sure if it's simpler on those devices to use an HTTP interface (because HTTP requires a bit more overhead data) but it might be simpler, sure.
      • zAy0LfpBZLC8mAC 9y ago
        HTTP runs on top of TCP, which already gives you at least two round trips. Also, if it's a device that's connected via the public internet, you probably should be using TLS, which gives you a couple more round trips. Really, realistically, if your internet connectivity is too bad to support SMTP, it most likely won't work for HTTP either, and you probably should be using some custom UDP thingy with an appropriate retry strategy.
• vinaysshenoy 9y ago
  We were sending email via SMTP from our Android apps for a while until we ran into quite a few cases where SMTP was blocked at the router level. We had to move to HTTP mailing to let the mails go through.
• BrandoElFollito 9y ago
  For instance to send messages from client only web applications where the only thing you have is an AJAX call.
• Michielvv 9y ago
  In our case the reason we switched from SMTP to an HTTP API was mostly speed. At least for Sendgrid, their HTTP API is much faster than SMTP. In general I agree that I'm not seeing a big advantage in having another service to keep up and maintain, just to wrap SMTP.