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.
Related
Suppose I own an email 'demo#gmail.com'. Now, I create a new Microsoft account using my existing email. Thus I get another email 'demo#gmail.com', but this one is served by Microsoft.
So the situation is: one email and two providers.
If I send a hello email to 'demo#gmail.com' using my personal SMTP server, to which of the above will it send: will it send to the one hosted by Microsoft or the one hosted by Google?
How does it solve such an ambiguity? What are the factors that influence this?
This is a very common problem because many providers are giving us an option to create a new account using our existing email.
My observations:
I saw the emails inside the inboxes of both the services. I found that they had completely different emails.
There was no email which was common to both the inboxes. So there must be some mechanism to deal with it.
Let us look at the problem the other way round: If I had an email 'demo#outlook.com' initially and I created a new Google Account with this email address, then:
An email sent to this email address from another gmail account goes to the Google's server. An email sent to this email address from an Outlook also goes to the Google's servers.
There are two different ways of looking up an email. The 'normal' way:
You send an email to an server, in this example gmail.com.
Your mail delivery agent looks for mx record of gmail.comand send it to the ip-address of gmail.com.
If an email is delivered locally by the domain outlook.com it perhaps doesn't lookup the mx record, but lookups in a local database if the email-address exist there, and sends it to the ip-address of the outlook.com.
I think in the inbox of outlook.com are only microsoft emails.
More details can be found at https://www.socketlabs.com/blog/smtp-email-delivery/
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.
In my project when the user stored a new record to database, sent to him email with to perform afterSave() Method.
How to make sure that the email was sent?
I don't think this is something to do with yii2 or the afterSave() event (as long as the afterSave event is triggered, which you can verify by Runtime Logging for example). When using PHPMailer class you can see this discussion about making sure an email has been sent.
$mail->send() will not always return true. It returns true if the part of the sending process it was involved with works. So if you send to an unknown address, but do so via gmail, gmail's servers don't know whether the address exists or not at the time, so it will be accepted and bounced later. If you were sending to a gmail address when sending through gmail, then it would fail immediately.
If an account does not exist at all, most servers (including gmail) will still give a 5.1.1 "Unknown user" response, and that will be reported correctly by PHPMailer if you send by SMTP directly to the recipient's supposed mail server (but not if you send via an intermediate server (like gmail) or using mail()). PHPMailer doesn't have built-in support for doing that, but doing it yourself only involves a call to getmxrr and setting Host manually. Also you won't need to use authentication if you send that way.
You can do various things like check if a domain exists at all - if it doesn't, mail delivery won't work. Some servers will accept all addresses and send bounces later (e.g. if they have a spam filter with a long processing queue), but if you get rejected up-front, it's a pretty sure indication that the address doesn't exist.
You need to look into bounce handling too which will allow you to remove addresses that looked ok but later proved not to be, which is an entirely separate thing from anything that PHPMailer does. I will warn you now - bounce handling is extremely unpleasant!
You should also send using tls on port 587, not ssl on 465; see the gmail example provided with PHPMailer.
I would also recommend you to send mails via an SMTP auth connection trough PHPMailer.
I am building an app that incorporates Postmark App's Incoming Email capability to keep a threaded list of replies to an email. Their documentation suggests adding the post ID to the reply-to address - for example reply+POSTID#domain.com. However, when I attempt to use this method with cPanel, the emails are bounced back.
I have reply#domain.com set up, without adding the post ID the email is forwarded to the Postmark App inbox address, adding the ID breaks it. Is there any way to do this in a WHM/cPanel environment? It is a VPS account so I have full access if there is another way to tackle this.
Are the messages bounced back from Postmark or is it a cpanel error? I can probably help you out there! Do you have an MX record setup for Inbound via http://developer.postmarkapp.com/developer-inbound-mx.html ? Once you have that going Postmark will accept messages from any address on that domain and parse off the addresses with + chars in them. Are we sure cpanel can handle email addresses with special characters?
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.