When I first sent a test message with Amazon SES, the MAIL_FROM was 0101015825ed6274-5b0cad8d-ddb6-425b-9802-782cc554497a-000000#us-west-2.amazonses.com.
In most email programs that address is hidden in the header, and it appears to be FROM a more human-friendly address. This is not the case when using an email to MMS gateway, which displays the spammy looking MAIL_FROM address to the user.
I figured out how to change the MAIL_FROM domain, but that just changes it to something like: 0101015825ed6274-5b0cad8d-ddb6-425b-9802-782cc554497a-000000#my_domain.com.
Is it possible to change the spammy-looking string of characters in the MAIL_FROM to a customized, human-friendly, less spammy-looking local_part of the address?
It is not possible.
The local_part of the MAIL FROM address is a unique, opaque identifier that SES uses for feedback tracking -- linking backsplatter bounces from poorly-behaving mail gateways that "reject" undeliverable mail by first accepting it and then firing back a separate bounce message... as well as spam complaints and out-of-office auto-responders, back to the original sender, message, and recipient.
That's why of the configuration of a custom MAIL FROM domain involves setting the domain's MX record to point to feedback-smtp.[aws-region].amazonses.com -- it collects those responses and correlates them back to the original message.
Techniques of this nature are necessary due to weaknesses in the design of SMTP itself, where it is difficult, unreliable, or impossible to otherwise correlate such events back to the original message that actually triggered them.
Related
I will try to express my question, I'm sorry if is not the correct way to do it.
I have an AWS SES configured to receive emails from my customers, sometimes the client get in a list and try to send an email too large (above 10MB), and my costumer start to receive bounced emails from all recipients in that list.
The bounce happens when my client tries to send an email for another people but the email of my company appears on CC field.
E.g:
the client sent an email:
TO: wherever#google.com
CC: mycompany#mycompany.com (this one will be sent for my SES); [a lot of other emails.........list]
This mail will be more large than 10MB (my SES must have to treat it).
This chain wil generate an bounced mail for my costumer, once that my email appears on CC list.
It's a little bit complex to express, but basicaly is it.
I'd like to know if is possible to track this attempts when the costumer receive the first bounce email from AWS. and to trigger a alert for me that the costumer is getting in a bounced list.
You can absolutely do this, SES supports notifications per type to SNS. The types are Delivery, Bounce, Complaint.
Each type can be registered to an SNS topic which you can subscribe a Lambda function to.
This Lambda function can then perform any logical decisions that you would like for your workflow.
In addition you can subscribe any email addresses you want to receive the raw notification that it was undelivered, although you will need to confirm there subscriptions before they can receive notifications. This would be ideal for a support inbox for example.
The AWS documentation contains more information about notifications
I'm getting bounce when I send an email to a specific address using SES, from gmail the mail is delivered correctly
For Transient -> General AWS says The recipient's email provider sent a general bounce message. You might be able to send a message to the same recipient in the future if the issue that caused the message to bounce is resolved.
How can I fix the issue if I do not know the problem?
"eventType":"Bounce",
"bounce":{
"bounceType":"Transient",
"bounceSubType":"General",
"bouncedRecipients":[
{
"emailAddress":"{some_email}",
"action":"failed",
"status":"5.7.8",
"diagnosticCode":"smtp; 535 5.7.8 Error: blocked by Block Address check from 54.240.8.90"
}
],
"timestamp":"2019-07-03T19:48:56.445Z",
"feedbackId":"0100016bb962013a-6cd68815-3c51-4216-9946-50f01b923057-000000",
"reportingMTA":"dsn; a8-90.smtp-out.amazonses.com"
}
Not much you can do, seems like the recipient side is checking IP reputation and found that SES IP (sending IP) 54.240.8.90 is in the blacklist, it also sent you a bounce back with custom message "smtp; 535 5.7.8 Error: blocked by Block Address check from 54.240.8.90".
Seems like they're using SORBS SPAM .
https://mxtoolbox.com/SuperTool.aspx?action=blacklist%3a54.240.8.90&run=toolpage
http://www.sorbs.net/cgi-bin/db
Couple of things you can try:
Remove the IP from SORBS by yourself (it may get added again)
Contact AWS to contact them to remove it from Blacklist.
Try dedicated IP pool.
We're doing everything we can think of to limit the number of complaints we receive and will immediately remove anyone who marks us as junk that does not need to receive our emails. However, the last handful of complaints we've received have come from transactional emails of people who are receiving our company's services and NEED to receive everything we send transactionally as a critical part of our service. (e.g. We are booking their travel on their behalf and we need to send them verification emails to confirm their booking details.)
We're assuming that most of these complaints are somehow either false positives or are being done on accident. One customer confirmed that they did not click the junk mail button but it ended up in their junk folder and they moved it to their inbox. Some questions:
Can a TiS complaint be triggered by any means other than the user manually marking an email as junk in their email client? (Can automatic spam filters trigger this complaint? AWS documentation specifies only clicking the junk button.)
Besides contacting each individual personally, what would you suggest we do? Our complaint rate is continuing to rise even though we are taking action on every one.
Setting up Meteor to use "out of the box" AWS SES is simple, and one can use native Meteor "Email" methods without modification.
Steps to implement this can be found here. Thanks to Brian
Shamblen for putting together a detailed answer.
But one caveat with the "out of the box" SES is you need to both verify the sender and receiver email address.
To remedy this, you can put in a request with AWS SES for what they call, Production Access.
And further, according to Brian Shamblen,
The process to get production access is rather complicated. One will
need to handle bounce and complaint notifications from SES and prevent
messages from being sent to those addresses in the future.
Question
What is the Meteor code involved in handling bounce and complaint notifications from SES and prevent messages from being sent to those addresses in the future?
EDIT: Made modifications to question for clarity.
Requesting production access is fairly straightforward. You just need to contact them and they usually give it to you in a couple of hours.
Information about the process is here: http://docs.aws.amazon.com/ses/latest/DeveloperGuide/request-production-access.html
Load up the URL : http://aws.amazon.com/ses/fullaccessrequest/ and let them know what you will be sending via Emails, for example if you will be sending transaction based email (verification of a transaction, etc)
With production access you can either send email from:
A specific verified email address, where you will be asked to click a link to an email sent to that address to verify you own it
Any email under an entire domain. Under this process you prove you own the domain by editing its DNS records to contain a 'key'.
Most use cases are covered under production access, they typically give you 2000 emails a day and rate limit emails to 5/sec (they queue them so the maximum send rate is 5/sec). If you need more than this you can contact them to raise this additionally.
The process of verification is to stop people quickly creating AWS accounts to mass-spam users. If they allowed this straight-off then AWS IPs would be looked at as spam by other email providers.
For bounce notifications, SES tracks these, and you have to make sure that you don't get an above average bounce rate. Typically these would come from sending unsolicited email, which I wouldn't advise sending via SES.
Production access is only approved by the AWS team. Wait a bit and they should easily give you 2.000 emails/day for free.
As per bounces-unsubscribes... You'll need to have the SES API notify you of each email address which has been 'marked' with such status.
You should store all those email addresses somewhere and tell your app not to send them ANYTHING else in the future.
I want to process incoming forwarded emails received by procmail to grab the subject and recipient of the forwarded (child) email.
For example:
UserA receives an email from UserB
UserA forwards that email to the email server
email server receives the email and extracts UserB's email address
Is there an approach or recipe that performs this task? Or do I have to regex my way through the body of the main email?
EDIT:
By request, I will offer boundary conditions. Email clients of the 'UserA group' are Gmail and Outlook. All users sending in English. The 'UserB' is an automated agent under my control.
One of my servers ('User B') sends automated emails to my users ('UserA') who are supposed to forward the email to a second server for processing (to confirm they received the automated email).
I assume, then, that there are no consistent headers for forwarding and that I am needing to regex my way through the email to extract the data I need.
(This isn't really a proper answer, but I cannot use formatting in comments, so here goes.)
Depends on what you mean by "forwards". If you mean "uses the 'Forward' button in a sane email client" it could come out as an attachment (possibly with a content-transfer-encoding which needs to be decoded in order to access it) or an in-line copy of the original message as a textual body; or if you mean "uses the 'Forward' button in a broken email client, such as anything from Mordor Redmond" there are a number of possible additional complications. Technically, some clients might also "forward" by adding a "Resent-to:" header and otherwise just resending the original message verbatim. Or in some modern clients, you could drag the message over into the composition pane of a new empty message, and make it appear as an attachment to the new message, possibly with user control of the containing message's content-type and encoding, and the attachment's.
Assuming you end up with something like the following ...
From: UserA <usera#such.example.com>
To: server#example.net
Subject: VB: Hi
Hey, here is a message I received.
-- User A
---- Ursprungligt meddelande ----
Från: UserB [mailto:userb#elsewhere.example.org]
Till: UserA
Ämne: Hi
Datum: perjantai 13. lokakuuta 2012 23:45
Here is the original message
-- User B
.... the representation really isn't suitable for automatic processing. You can come up with heuristics such as identifying the "original message" separator and the first (possibly localized and mutilated) "to:" field after the separator, perhaps by requiring all messages to be from a particular version of a particular client with a particular locale setting, but in the general case, this cannot be solved reliably.
(For fun, I constructed an example from a Swedish localization running with Finnish system settings; so the labels from the client are in Swedish, but the system's date is in Finnish.)
If you can edit your question to include an example of a forwarded message and maybe some boundary conditions (it's always from the same user, the version and localization of the client software she uses will not change, etc, perhaps) we can try to take it from there.