6 ms·

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 ou

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 everything himself :) and your customer's mail is sitting in a repeat-later loop for 5 days. Once a message is received, are you sure you'll figure out the encoding of it? Or what happens if your process/machine is down when the message arrives? What if it's spam? And why not record computer-to-person email conversations you're software is doing in a real POP3/IMAP mailbox? No coding required. On intelligent processing: we transcode all your traffic to UTF-8 and figure out what parts of the message is quoted - so you won't have to. It's not easy, ever wondered why some folks resort to "reply above this line"? Also, if there's no plain text part, we'll generate it from HTML. More is coming. Mailgun is not an email sending service. We're a full-featured programmable ESP, it's up to developers what they want to use our email servers for. The creative ones keep amazing us every day! :)

staunch 15y ago
I don't like to do everything myself. I'm actually very inclined to outsource stuff like this. It doesn't sound very interesting for sending email. The receiving part is more interesting. Still, it doesn't seem like it would save me enough time to warrant implementing your API, dealing with yet-another-service, and paying. I don't mean to be too negative. One of my favorite kinds of businesses is taking something every company already does and "productizing" it. Maybe I'll get tired of dealing with it myself and sign up. Either way, good luck!
dools 15y ago
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 pretty good - how about offering them as a paid-per-transaction service? I wouldn't bother outsourcing the sending and receiving per se because it's cheap and easy to do that myself, and I then have control over the up (or down!) time but being able to pass a message through your service and pay, say, $1 per 1000 messages processed with no storage costs would be kinda cool. I'm imagining getting back some kind of structured document (XML and/or JSON) allowing me to see quoted messages, interleaved replies, attachments, encoding blah blah basically all that stuff you're talking about.
- tworats 15y ago
  Would love to learn more about the SMPP server and your setup, is there a writeup or pointers to more info anywhere?
  - dools 15y ago
    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/16642 http://comments.gmane.org/gmane.comp.mobile.kannel.user/1664... I've been using the same setup for years with no problems.

staunch 15y ago

I don't like to do everything myself. I'm actually very inclined to outsource stuff like this. It doesn't sound very interesting for sending email. The receiving part is more interesting. Still, it doesn't seem like it would save me enough time to warrant implementing your API, dealing with yet-another-service, and paying. I don't mean to be too negative. One of my favorite kinds of businesses is taking something every company already does and "productizing" it. Maybe I'll get tired of dealing with it myself and sign up. Either way, good luck!

dools 15y ago

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 pretty good - how about offering them as a paid-per-transaction service? I wouldn't bother outsourcing the sending and receiving per se because it's cheap and easy to do that myself, and I then have control over the up (or down!) time but being able to pass a message through your service and pay, say, $1 per 1000 messages processed with no storage costs would be kinda cool. I'm imagining getting back some kind of structured document (XML and/or JSON) allowing me to see quoted messages, interleaved replies, attachments, encoding blah blah basically all that stuff you're talking about.

tworats 15y ago
Would love to learn more about the SMPP server and your setup, is there a writeup or pointers to more info anywhere?
- dools 15y ago
  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/16642 http://comments.gmane.org/gmane.comp.mobile.kannel.user/1664... I've been using the same setup for years with no problems.