I am using the SES email library from amazon to send text messages by sending them through 5556665555#vtext.com for example, or just an email itself. However, recently some of the text messages have headers that show the from address as something like this:
0000013a94c84b04-4f0a3d49-483f-4dfb-8b8c-87a33698a35f-000000#amazonses.com even though the same email ends up in my email with regular from address. What could be the culprit/solution? This had worked fine previously with no change to how headers are dealt with ( I am using amazons SES library and haven't mucked with internals). The code is the exact same when I send it to a regular email address or an SMS gateway address.
UPDATE
I have realized that vtext changes from address to the ReturnPath Header, giving me the long drawn out address. I have tried setting the opt variable to contain 'ReturnPath', 'me#me.com' so when I call $ses->send_email($this->source,$this->destination,$this->message,$this->opt); it does pass it in, however, this is being ignored anyways. How can I force SES to respect the ReturnPath header, or alternatively, have the correct From address show up.
What is troubling is that ReturnPath is used for bounce reporting, so if this hack for verizons broken system is in place, I will no longer receive bounces.. but that is the best I've got at this point.
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've implemented List-Unsubscribe (RFC 2369) for marketing emails we send. I am providing both an unsubscribe email address and an unsubscribe URL. An example of a generated header looks like this:
List-Unsubscribe: <mailto:unsubscribe#myserver.com?subject=unsubscribe>, <https://myserver.com/unsubscribe?email=recipient#email.com>
In the past few email campaigns we've done, it has worked great. There's only one problem. Sometimes we receive unsubscribe requests from email addresses we didn't actually send mail to. I think this happens when the user has multiple email addresses and the email we send is forwarded to some other destination. So we send to user-a#email.com, but the recipient opens it at user-b#email.com. When they click the "Unsubscribe" link provided by their email client, it generates an email to us telling us to unsubscribe user-b#email.com.
Sometimes we can find the intended address if the address we sent to was very similar, or if the user has a unique name, but sometimes it's impossible to determine which email address we should unsubscribe. That's frustrating because we know the user will be upset if they receive another email from us in the future.
I tried to fix this by adding a unique identifier to the subject line, so that a subject looks like unsubscribe_20934832034820348, but when we do that, email clients stop showing the Unsubscribe button. It's as if they will only show the Unsubscribe button if the subject line is exactly "unsubscribe".
I didn't see anything in the RFC about the subject line needing to take a particular form, and we are also taking care not to put the user's email address directly in the subject line. (It is a hashed combination of their email address and a portion of the original message, making it unique across all emails we send.)
Is there some sort of convention around this? If so, how can I reliably determine the original address we sent to when we receive unsubscribe emails?
It looks like there is no problem using this sort of subject line. However, it seems that each email client decides in its own proprietary way when and how to display the Unsubscribe button/link, and it does seem that that when you change from a simple "unsubscribe" to "unsubscribe" plus some unique identifier, some clients might subject you to some sort of test period before showing the link to users. In my testing, Gmail did not show me the link when sending small batches of test emails, but after I sent a large batch of emails, the link did start appearing, and I did indeed receive the generated unsubscribe mails properly.
I hope this helps someone out there.
I run a WorkMail client which is used to view emails received by SES. I want to set up a lambda trigger than when it detects an email from an external client, I want certain text to be censored or add an [EXTERNAL] tag to the email before the user can view the email in WorkMail. So far, the only possible manipulation I've been able to do to the email is add headers which as far as I'm unaware, will be invisible to any user viewing the email in any client until they inspect source.
I'm essentially asking if this is even possible really, as it is something I've been tasked to do from my superiors. The only method otherwise of editing the emails I can see is downloading the email, then resending it after editing with a reply-to being the original sender.
When sending bulk emails I was receiving several error messages that said:
553 5.1.3 The recipient address <john#example.com > is not a valid RFC-5321 address.
The format of the email addresses looked completely valid so I couldn't figure out at first why these messages weren't being delivered.
Upon further inspection, I noticed that the recipient email addresses for each of the failed messages had a single space on the end. It's not as hard to see in the example I provided above, but the error report I was viewing had smaller font and would sometimes put a line break where the space was, so it wasn't as obvious. By the way, I was using the SendGrid API to send these emails, but I don't think that the issue would be unique to using SendGrid.
if you are using node.js API for sending emails to people, you just need to add .trimRight() to your recipients email address in your API, so in this way the white space will be removed and you can successfully send your email. :)
I was using Django Restful Api and my mistake was, when registering the users, I had interchanged the email field with the username field. So the Smtp server was using the username as the email address used to send the verification emails. I corrected that interchanged the fields correctly and it worked.
I'm creating an email a friend type system where I need our mail server to send emails from the user of the site to their friend, i.e. from fred#gmail.com, to tony#gmail.com.
If, as is the case in this example, the user's are both part of Gmail the friend would receive an email with the warning "This message may not have been sent by: fred#gmail.com.
I thought that by then adding a 'sender' header with our email (e.g. us#company.com) this should indicate to Gmail that we are the sender and are effectively openly spoofing the sender at their request. Is this true, can you get around Gmail's warning using the 'sender' header?
I realise this is similar to the following question but I'm more interested in whether the sender header should have an effect: Email sent from web server causes gmail to treat as phishing. How to get rid of this?
More info:
I'm using netmailbot to send emails from our mail server using the '-customheader' parameter with 'sender' and 'x-sender' e.g. '-customheader sender:us#company.com x-sender:us#company.com'
If gmail doesn't fail miserably, you have no way to suppress this warning.
Google is in control of both accounts and therefore knows, that this mail wasn't send by fred using their infrastructure.
There was used some third party infrastructure (yours) and this is all this warning is about.
You can set an arbitrary email address as "from" and Google has no knowledge if this is legitimate use (if fred really wrote the message). Anyone could have written that message. Normally fred would use Googles infrastructure to send mails and then they would know its him.
A cleaner solution would be to put your email address ("noreply#company.com") as from header (that would be honest) and set fred#gmail.com as reply-to header (so he gets the replies).