I have a situation where we have users who would like to message a different user type, let's call them client and provider.
We don't want to set up a whole messaging system because not all providers will be using our infrastructure.
Therefore we would like to implement the following flow:
Client clicks 'email provider'
native email client opens up with a dynamically created email address such as 'message-provider1234#ouraddress.com'
Client sends an email to this address
Our system forwards this email to the provider's real email address
Provider replies back to our email
We forward this email to the original sender (client)
Does anybody know if there are any exisitng solutions to this? Or guidance as to how we might go about implementing?
Related
this is a pretty specific case, but it drives me crazy...
We recently migrated our email service to google workspace. We do have an invoice#mydomain.com address which earlier was configured to forward emails to someinbox#datev.com. someinbox is a mail upload feature for tax related invoices of our company. The problem started when i was trying to set up the mail filter in Gmail.
All emails with an attachment should be forwarded to someinbox#datev.com. To forward emails with Gmail, google needs to verify that I am allowed to forward to that specific address. It therefore now sends a confirmation email with a link to that address. that email is being sent by eg. noreply-forwarding#google.com, which is being rejected (550 5.7.1 Security policy violation: sender address not authorized). The problem is, datev only accepts emails from "verified sender addresses". It does that verification by also sending an email verification to that "verified sender address". Which in my case now becomes the noreply-forwarding#google.com, which I obviously not maintain and therefore i am unable to verify that address.
So I am unable to add the forwarding email address in Gmail, because of the sender google uses to verify the forwarding address.
We use google workspace, so I am able to use the pretty cool routing feature of Gmail. First I created an email-alias called datev#mydomain.com. I then setup a rule which simply changes the envelope-sender to someinbox#datev.com if the envelope-sender is datev#mydomain.com. that part works. If I send an email from the invoice#mydomain.com to datev#mydomain.com it changes datev#mydomain.com to someinbox#datev.com.
The next problem was, every forwarding (which the Gmail filter was doing) works by sending the same email to someinbox#datev.com while keeping the original sender. That also happened when I tried to do the same workaround by creating a new email forwarder (or even a mailbox) on a different domain without google workspace. I also tried it using posteo. The original sender is being used as the sender address and therefore datev rejects it. It wouldn't be possible to register all sender address as we get a lot of invoices from business partners.
Does anybody know or see a way of doing this? Aren't there any secure email forwarder which replace the sender address to the one of the forwarder instead of keeping the original one? I know, this is in most cases a pretty nice feature as you can see who the email originally sent, in my case it makes me nuts.
I have a use case for an email flow that looks something like this:
1) User sends an email to a specified address
2) Service receives the email and pings a webhook with the email in json format
3) My webhook/backend runs a quick check on the sender's email address and either:
4a) Creates an email and sends it as a reply to the original user, or
4b) Forwards the original email to another destination (it's important that the forward email retains the original senders address/reply-to etc.
Ok, I can easily get as far as 4a) using one of a few services (PostmarkApp, Mailgun, etc), but I'm struggling with 4b) - forwarding using an API.
The closest I can get is to receive the email into my Mailgun account and set a route that both stores it, and pings a webhook URL.
It then seems like I should be able to instruct Mailgun to forward the stored email to the final destination - but I just can't figure it out.
Anyone been here before?
I'm asking here before trying Mailgun support.
Thanks.
In our SaaS application each company (tenant) is given their custom domain like companyName.ourapp.com
We would like to provide some email services like:
Ability to send and receive email notifications from info#companyName.ourapp.com and similar addresses
Ability to create new email accounts in clients' subdamains at runtime, programmatically, when needed. For example we would have separate emails created for each "opening" so that emails sent to this address would be parsed info would be extracted
Similar tasks
For now I just don't even know on where to look and how this could possibly work.
As far as I understand email it should be some kind of custom mail server (SMTP) serving all sub-domains and having API we can use to send emails, list and retrieve messages etc.
Please suggest how it may work and is there any components out there we can use to implement this.
There are three options for this.
Create an email server and programatically configure it to accept or deny the specific accounts. Then use cron to poll via pop3 or imap and download the messages for the account. You can then send them on for the customer or handle them in your web app.
Create a script that is fired by the email server as it receives each email. The script can then handle what to do with the email as it's received.
Use a third party to receive the email via HTTP Post at your app. Using CloudMailin for example would allow you to create a custom authorization filter that would call your app in realtime and determine if the given account exists and messages should be accepted for it.
I wrote a blog post for Rails about receiving incoming email, however the principals would apply to any programming language and framework.
My goal is to create a canned email on my server and then send the email from client email addresses. To do this and not be marked as spam I understand it must come from a domain matching the from address.
There are many user email addresses I would need to send email from, all with the same domain. With cooperation from my client, could I set this up to work with one SMTP credential or would I need credentials for each and every individual user?
To clarify, if I get an SMTP server address with a un/pw from my client, would that be enough to send from:
george#example.com
martha#example.com
ted#example.com
Thanks!
It depends completely on the SMTP server you are using. Some servers will allow this, like Google's SMTP, but it will attach a Sender header to the outgoing message when the From header does not match the authenticated account.
Example:
You authenticate with joe#gmail.com
You send out with From: bill#gmail.com
The message will contain From: bill#gmail.com, but Google will attach
Sender: joe#gmail.com to the message headers.
So, it completely depends on the SMTP server and their policy.
Problem
You want to avoid joe-jobbing in your automated messages.
Your Options
It depends on how you're submitting jobs to the MTA.
If you're authenticating to a remote SMTP server for each message, then you need credentials for each user.
If you're injecting messages directly into an MTA (e.g. with the sendmail command) that is authorized to send mail for the domain, then you only need privileged access.
I have a web app that only registered users can use, therefore I should have a valid e-mail address for the creator of the message.
One part of this web app will allow a user to create and send a e-mail message to an e-mail address that the user enters. My web server will be creating and sending the e-mail, however if there is a delivery problem with the e-mail I would like the bounce to go to the user's e-mail address instead of the server. This will allow the user to know that there was a problem delivering the message and they can take the appropriate action.
Would setting the "return-path" attribute to the user's e-mail address handle this?
As RFC2821 says:
The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. For this to be unambiguous, exactly one return path SHOULD be present when the message is delivered.
So yes, all standard compliant servers should account for the Return-path you set.
You could set up windows service on your server to periodically check BadMail folder and parse the bounced messages and resend them to the original sender. This solution would work in most cases. I don't think return-path would help in every instance (if it would at all), because different mail servers handle bounces differently.