Can anyone comment how this compares to context.io? (which also appeared on HN)
It seems to me that the analogy "Twilio for email" works better when applied to context.io, which aims to give a uniform API to all mailbox operations.
Mailgun (YC W11) Raises $1.1 Million For Its "Twilio For Email"
61–70 of 71 posts
Re: Mailgun (YC W11) Raises $1.1 Million For Its "Twilio For Email"
#62Earlier quoted context omitted.
Staunch: there will always be guys who want to do everything themselves. But we're selling to folks who have other things to worry about. Risking to re-type our own front-page, I'll go ahead and give you some tips for how Mailgun can be useful: Once a message is sent, what happens to it? We give you searchable SMTP logs: see if some crazy admin guy in Canada misconfigured greylisting (because he likes to do everythin…
Automatic detection of which bits are quoted sounds good. Having just gone through the process of setting up a VPS to handle sending and receiving email, processing bounces and recording delivery receipts I'd say that, fundamentally, this isn't challenging. Then again I've also setup my own SMPP server for sending SMS and didn't find that particularly difficult either :) Some of the inbound processing features sound…
Would love to learn more about the SMPP server and your setup, is there a writeup or pointers to more info anywhere?
Re: Mailgun (YC W11) Raises $1.1 Million For Its "Twilio For Email"
#63Can anyone comment how this compares to context.io? (which also appeared on HN) http://context.io It seems to me that the analogy "Twilio for email" works better when applied to context.io, which aims to give a uniform API to all mailbox operations.
context.io turns mailboxes into databases you can tap into. They are especially good with attachments. is there an API call to send or receive email with context.io? I am not sure.
from what I get, mailgun makes it easy to send/receive emails, so that email is a completely integrated feature of your web app, meaning users won't even have to check their email, the experience is all within the app. You can also do it the other way around with mailgun, which is interacting with the user in his email client, so he doesn't have to go in the app.
Re: Mailgun (YC W11) Raises $1.1 Million For Its "Twilio For Email"
#64Killer service, but two things jump out. 1) Need dkim signing by own domain and 2) envelope sender should match from address. These don't matter if you're sending to consumer domains (gmail, yahoo), but, as I've learned, they do matter for corporate environments, which are fragmented and antiqued.
Re: Mailgun (YC W11) Raises $1.1 Million For Its "Twilio For Email"
#65ok why does everything these days have to be described as "Twilio for XYZ"
No disrespect to twilio, I think they've done a great job, but they aren't huge yet. They also weren't the first infrastructure PaaS to hit the market.
Re: Mailgun (YC W11) Raises $1.1 Million For Its "Twilio For Email"
#66Earlier quoted context omitted.
Actually we do "everything email": Detailed searchable mail logs: we actually tell you what happens to every single one of your messages - nobody else is that brave! Incoming email push - and our parsing/cleanup of incoming traffic is pretty impressive - if it's time to self-promote, it's now. And our incoming email handling if flexible: we do routing/forwarding, similar to Rails/Django routes. Storing/hosting your e…
This a completely off-topic and pendantic, but I just thought I'd throw this out there. On this page: http://mailgun.net/pricing I personally have a hard time parsing how much money $0.5 is. I'm assuming you're charging 50 cents per 1K messages. My mind groks $0.50 per 1K messages, much more easily.
Thanks for sneaking a grok in there. HN just wouldn't be the same without hipster buzzwords!
Re: Mailgun (YC W11) Raises $1.1 Million For Its "Twilio For Email"
#67Earlier quoted context omitted.
With a little bit of coding on your part - yes.
I'm curious about this. I found the tagging functionality for outbound mail. If I tag an outbound message, and someone replies to it, can I easily read back the tag from the reply message? Put another way--I want to send an outbound email in relation to a specific thread/ID, and if someone replies I want to associate their reply with that ID. What's the best way to do this with your system?
For your use case I would add your own Message-ID MIME header to the
outgoing message. When a user replies, usually (in most cases) you'll
see the ID of the original message as In-Reply-To header.
And it will be posted as In-Reply-To HTTP parameter to your app. There's also "References" MIME header you can use.
I hope this helps.
Re: Mailgun (YC W11) Raises $1.1 Million For Its "Twilio For Email"
#68Can anyone comment how this compares to context.io? (which also appeared on HN) http://context.io It seems to me that the analogy "Twilio for email" works better when applied to context.io, which aims to give a uniform API to all mailbox operations.
context.io turns mailboxes into databases you can tap into. They are especially good with attachments. is there an API call to send or receive email with context.io? I am not sure. from what I get, mailgun makes it easy to send/receive emails, so that email is a completely integrated feature of your web app, meaning users won't even have to check their email, the experience is all within the app. You can also do it t…
Hey guys, it's Sarah-Jane, Community Manager at Context.IO. Yup, you got it. We don't host dedicated mailboxes that your application can receive and send emails from, but since we make the contents of any IMAP account available to your app, whatever is received in that account is like your app receiving it. For the sending part, we're leaving that to Mailgun and other services that focus on this.
Re: Mailgun (YC W11) Raises $1.1 Million For Its "Twilio For Email"
#69Earlier quoted context omitted.
context.io turns mailboxes into databases you can tap into. They are especially good with attachments. is there an API call to send or receive email with context.io? I am not sure. from what I get, mailgun makes it easy to send/receive emails, so that email is a completely integrated feature of your web app, meaning users won't even have to check their email, the experience is all within the app. You can also do it t…
Hey guys, it's Sarah-Jane, Community Manager at Context.IO. Yup, you got it. We don't host dedicated mailboxes that your application can receive and send emails from, but since we make the contents of any IMAP account available to your app, whatever is received in that account is like your app receiving it. For the sending part, we're leaving that to Mailgun and other services that focus on this.
hey Sarah-Jane, the reply above was from me heri from @mtw
Re: Mailgun (YC W11) Raises $1.1 Million For Its "Twilio For Email"
#70Earlier quoted context omitted.
Automatic detection of which bits are quoted sounds good. Having just gone through the process of setting up a VPS to handle sending and receiving email, processing bounces and recording delivery receipts I'd say that, fundamentally, this isn't challenging. Then again I've also setup my own SMPP server for sending SMS and didn't find that particularly difficult either :) Some of the inbound processing features sound…
Would love to learn more about the SMPP server and your setup, is there a writeup or pointers to more info anywhere?
Hey, sorry I just checked this thread. I just use Kannel! You can use Kannel with a GSM modem as a "fake SMSC" or you can get an SMPP connection to one of the many SMS aggregators worldwide that allow it. SMPP is generally faster than HTTP in terms of throughput, but in terms of functionality (for example, setting the sender id) most aggregators have comparable offerings in both SMPP and HTTP APIs.
One major difference I've found with SMPP vs. HTTP APIs is on the inbound side of things - ie. receiving messages on a virtual number. Some aggregators I've used don't pass the UDH (user data header) through in inbound requests so you can't stitch long inbound messages together (this is, in my opinion, the driving force behind Twitters much vaunted 140 character limit - if they'd had an SMPP connection with the UDH in-tact they wouldn't have had to restrict posts to "140 characters reserving 20 characters for the username).
Even with kannel, though, you still need to stitch long messages together manually. I posted my sample implementation for this in PHP to the Kannel lists a few years back:
http://comments.gmane.org/gmane.comp.mobile.kannel.user/1664...
I've been using the same setup for years with no problems.