Loading Profile...
I would like to get some of mailgun's functionality in the Email Parse API.
The current implementation allows you to have a single URL end point for a domain.
Mailgun allows adding regex rules on the "from" address which allows mapping certain addresses to different URLs. Also, they support an Email end point which simply forwards the Email to a different box.
This allows me to have different HTTP endpoints for different addresses as well as forward some of the Emails to a real email box (in the domain I don't use for Email parsing).
It simply saves me a lot of glue code that is not necessary or needed and makes SendGrid sort of a router for incoming Email requests.
Help get this topic noticed by sharing it on
Twitter,
Facebook, or email.
Twitter,
Facebook, or email.
I’m
sad
Enhance Email Parse API to support multiple end points
-
I've already answered a pretty similar but older question here:
http://community.sendgrid.com/sendgri...
It's more work for you, but I still think you're better off doing your own routing. The problem has more subtly than it seems at first glance.
examples:
we don't want to forward spam, but accurate spam detection is hard. So do we drop suspected spam? what about false positives? Should we maintain a quarantine for suspect messages? white/black lists?
If we forwarded the incoming message for you, you'd be charged an email credit for it. Are you willing to pay a large overage for receiving a flood of spam the we didn't catch?
What if we were to offer a compromise? The reason it's so hard to build the glue code is there aren't many examples. What if we put together one or two good sized examples using the parse api? Some good examples with some easy/common use cases would take some of the pain out of it, right?Comment -
-
I’m
undecided
Thanks for answering. When I wrote this suggestion I was thinking of 2 major scenarios that I have encountered and I think others have too.
Before I start I just wanted to say that I love SendGrid and the fact that it's a cloud service in which I don't need to run my own servers to handle outgoing or incoming emails is great.
Scenario #1:
I want different HTTP handlers to different rules. This shouldn't be a spam issue because I simply want you to do the routing for me. The reason I want this is that it will save me servers and/or glue code. I can route requests with any of the web servers but SendGrid being a cloud service is more, in my opinion, about making it easier for me as a developer and reduce the code I need to write and configuration I need to make. Also, in some PaaS platform like AppEngine I don't have access to a router before my code like apache or nginx and I can't rewrite the request before it gets to my code. Writing a router on my code has its own problem, taking a connection and time of the request that I shouldn't even use.
This seems rather easy and doesnt have any effect on spam handling since it will simply call a different URL in certain cases.
Scenario #2:
You have already taken my MX records for mydomain.com when using parse API, so every thing is routed to my http handler. But what if I need some email to be forwarded to a real box? I can write code to take all the parsed data you sent me, reassemble it to an email and send it (via SendGrid) to another email box on another domain, however it's just glue code that I don't want to write, use or implement. It's easier for you to do that and save me the reassembly of the message. I this case, SPAM is an issue and I dont have a good solution here but I will think about it more.
Having examples for the glue code is nice but will you cover all programming languages and web frameworks? I don't think it's feasible.
As I see it, I use cloud services to save me servers (and therefore money) as well as code. The less code I write and maintain (specifically glue code) the less bugs and things I need to worry about myself and that's the beauty, IMHO, about cloud services.
Some of your competitors do have these options and at some point if maintaining this code or needing to do various other things to make it work will become a hassle I will just move to a different provider which does provide me with these abilities. -
-
I agree there are some people where Scenario #1 where we could help them by adding some basic routing mechanism. The reason it isn't a higher priority is the I suspect for the vast majority of use cases a simple router doesn't do enough, and you'd implement your own anyway.
That said I could be wrong- if this issue gets a lot of votes it wouldn't be that hard for us to put something together. -
