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.
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 web application that will be used by committee chairs to communicate with committee members over email. All these users will have e-mail accounts external to the web application and domain the web application is hosted on. Any replies from members need to be directed to the e-mail of the committee chair user, not an account on the domain of the web application. The only two methods of accomplishing this that I've come up with are
In the from of the e-mail, use the e-mail of the sending user. E-mail applications for many of the committee members block this as spam.
Use an account such as no-reply#applicationdomain.com, and then include instructions in the e-mail of the correct address that replies should be sent to. Users often get confused and don't send replies to the correct address.
Are there any alternatives I am missing?
Traditionally, this was the purpose of the Sender email header. If you want an email to be From the user, but sent by you, you would just set the Sender header to an email address on your domain but have From be the user. Also, the SMTP envelope sender should also be on your domain. Then, you would be properly declaring that you're the sender of the message for anti-spam purposes, you'll receive any bounce messages, but email clients will know that the email is reportedly from the "real" user, and will direct replies accordingly. Generally, email clients would report both Sender and From, saying something like "From my-server#website.example.net on behalf of real-user#example.com", though obviously the details depend on the email client being used.
Refer to What's the difference between Sender, From and Return-Path? and OpenSPF Web Generated Email Best Practices for more information.
However, now DMARC has come along. It has made the decision that verification should be based only on the From header. The theory is that there's no way for an end-user to know whether a particular Sender is in fact authorized to send mail "on behalf of" the user listed in the From header. While it probably isn't the decision I would have made due to how it ignores the traditional Sender, it's something that needs to be dealt with now, as if the domain of the user listed in the From has a DMARC record that is set to q=reject, then nobody else, including your web form that's trying to send mail with the complete approval of the user, can send mail that's From that domain. More and more domains are turning on DMARC, and as they do so your form won't be able to send email From them, regardless of what other headers are set.
The only other alternative, then, is to have email be From your application entirely, but set the Reply-To header to where the email program should send replies to. Also, the SMTP envelope sender should be your application, and ideally be set to an address that can handle bounce messages or other errors. You shouldn't need to include any instructions, as the Reply-To header is very well supported among email clients as indicating where replies should be directed.
Refer to the DMARC FAQ entry "Why are messages I send on behalf of visitors to my website being blocked?".
Background: I was handed the reins for our company's AWS account to implement a process to make sure our SES delivery report notifications can get acted on instead of just being filed away or deleted.
That said, the first hurdle is that the email address associated with our company's helpdesk keeps receiving all Amazon SES notifications for bounces, complaints and delivery failures. This creates a mess for our support staff in having to wade through these emails individually, and our ticketing system doesn't have the capability of auto-forwarding emails even though I can categorize them based on rules when they arrive.
I have read through all the knowledge base articles for SES notifications as well as ~380 forum topics relating to email notifications, but I didn't see an answer posted this question even though it had been asked a handful of times.
What we've done:
Set up a dedicated email inbox for these requests so we can then process them correctly (that we want to divert these messages to).
Created an SNS topic with the new email address as its endpoint and applied it to all categories, but the emails still kept going to support, so that clearly wasn't the solution.
Removed all hard-coded references to these emails from our software code, but we still get individual Amazon SES notifications to the helpdesk (~30 a day).
Simple idea, but AWS is pretty intimidating especially for our small company where no one has taken the time to learn through the ins and outs after first setting it up (fire and forget).
Edit for clarity, the emails I'm trying to redirect are "Delivery Status Notification (Failure/Delay)" and "Undeliverable:..."
Here's how i got this to work:
Under "AWS SNS"
Create an SNS Topic
Create a subscription to the topic that sends an email to your desired "catch address"
Confirm this subscription by clicking the link sent by AWS to this address
Under "SES Management - Identity Mangement"
Verify a domain or email address
At the domain/email address go to Notification and DISABLE Email Feedback Forwarding
Same place select your SNS topic for Bounces and Complaints
Under "SES Managment - Email Receiving"
Create a Rule set and then create a rule with the domain or email address above
Make the action the SNS rule above
When sending mail be sure that the From address is using the domain/email address above. All bounces and complaints should now end up in the catch address inbox. ALL OF THIS must be setup in the same region.
These notifications are configured either at a verified Domain level or at a verified email address level. This page has info on it. At the bottom, it talks about how you can confirgue to have messages sent to email or a SNS topic. You probably have a notification setup on your domain or the specific email address you are using.
You'll find all this in the SES section of the AWS Console under the Identity Management section. Make sure you check both the Domains area and the Email Addresses area.
You make the feedback address differ from the sender by setting the Return-Path header in your message (subject to a few other rules):
From the developer guide:
If you used the SMTP interface to send the message, then notifications go to the address specified in the MAIL FROM command.
If you used the SendEmail API operation to send the message, then the notifications are delivered according to the following rules:
If you specified the optional ReturnPath parameter in your call to the SendEmail API, then notifications go to that address.
Otherwise, notifications go to the address specified in the required Source parameter of SendEmail.
If you used the SendRawEmail API operation to send the message, then the notifications are delivered according to the following rules:
If you specified a Source parameter in your call to the SendRawEmail API, then notifications go to that address. This is true even if you specified a Return-Path header in the body of the email.
Otherwise, if you specified a Return-Path header in the raw message, then notifications go to that address.
Otherwise, notifications go to the address in the From header of the raw message.
I'm having an issue where outgoing emails sent through our CRM system are displaying the incorrect address for one of our customers.
The Return-Path value in the outgoing email header contains an address like sendername=company.com__<random letters>#<random letters>.crmdomain.com and this value is being displayed as being the 'from' address, instead of the address set as actual 'from' value.
We use DKIM keys, and this only occurs for one of our customers. Could this be due to their email client/server and is there anything we can do to handle this on our end?
This is most likely caused by their mail system configuration, and to fix this, you will probably need to work with their IT staff.
Do you know what mail system they use? Both their transport agent (mailserver) and their user agent (mail program on PC) could be at fault.
If your customer is tech-savvy, he/she might be able to extract mail headers from one of the mails you sent them, and forward this information to you for better analysis. However, depending on the type of client and your relationship to them, this may violate their corporate security rules, so you should check with the people in charge at their company.
Just for knowledge purposes, I want to know if it is possible to know if email spoofing has been done successful or not . Suppose if I am sending an email from one's account, What if receiver doesn't exist? Means will i get any error as a spoofer that receiver doesn't exist and you cant send email . Thanks
There is no way to know for certain, but you can make an educated guess.
First, when sending an email to a non-existent recipient and the recipient's server is configured to report this to the sender (pretty much the default behaviour), this reporting can happen either:
1) During the email transmission. The SMTP conversation with the recipient's server may very well fail at RCPT TO: (i.e. when the recipient is specified) or at the end of the DATA or BDAT commands (i.e. when the email just have been transmitted and the server either acknowledges this or rejects the email). If you receive an 5xx-type response at either stages, or, well, anytime earlier in the conversation, you can be sure the recipient did not get the message. Validation during email transmission is common.
2) After the email transmission. Servers that don't do recipient validation on SMTP level will often accept and queue emails during the transmission, then generate a bounce report (also called a Delivery Status Notification/DSN or Non-Delivery Report/NDR) later and attempt to return it to the original message sender. As you have no access to the mailbox of the original message sender when spoofing, you will have no idea if such bounce report is generated. This method of validation is still fairly common.
Second, you can embed a tracking image in your HTML email to see if the email was opened. This works by placing a HTML <IMG> element in the email that points to e.g. http://example.org/tracking-1x1.gif?uuid=<id>. The idea is that you track whether that image was downloaded. Be aware that virtually all modern email clients will disable downloading images from unknown sources and some action is required from the recipient to enable downloading images.
Third, you can spoof the MIME sender only. Emails have two distinct set of addressee information: the envelope addressees and the MIME addressees. Emails are delivered based on what's written on the envelope, but email clients render the MIME information instead (what's inside the envelope). In other words, during the SMTP transmission you may specify a different sender address (MAIL FROM: command) from that in the email (From: header). The fun part is that bounce reports are sent to the envelope sender address, a.k.a. the Return-Path, so if you have access to the envelope sender mailbox, you can receive a bounce report no matter what stage it was rejected. Note that you will reveal yourself, either through the mail server logs or through the email header, where the Return-Path header will contain the envelope sender address.
Please use the above information for "knowledge purposes" only. Be aware that email spoofing is likely a crime in just about any country.