Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
Gmail gets flooded with spam emails from AWS Ses
After my spam email folder gets full the gmail is not getting any more emails. How can I report to AWS Ses not to send me an email from a specific AWS Ses Account.
Here is the details. I have contacted the company who is sending the emails. They are unable to solve the issue. ( In 3 years cant cope with change ).
I was once a permitted receiver but not anymore. Help would be appreciated.
Delivered-To: rifaterdemsahin#gmail.com Received: by 10.100.151.140
with SMTP id q12csp736984pja;
Thu, 22 Jun 2017 18:55:26 -0700 (PDT) X-Received: by 10.200.47.87 with SMTP id k23mr6662116qta.11.1498182926606;
Thu, 22 Jun 2017 18:55:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498182926; cv=none;
d=google.com; s=arc-20160816;
b=VjPlf2DSOO/X+jFewPovx0GPtS81NriE988G1yhFs0sWUAULrnp31pIDjiI3v/MC2h
VOJDD6IkKpp+gsU4gYLo8BRoS71ZiHtB6O7Yk1z5Nc7QKxk+FjBuGK75Y8qM3dObxCKU
FpZ3vwZrmwHbL8etRznU/DwfcN5f60GP45eINzKe7QYS+HOquiISKfFI6Kjac5/GvHqu
fRL2zdFHu5E2aIXGUMUK4EdVsFjMQUsJUqBJC0OSoqLesyLdoyqV4oTAunH8BwYKWEY4
/JTNP2zR6+6wucgfEVVPUQ5W6ocKVWPlJnHDw+vP1y6JkKMNaNj9mYl0LORMKHU71ptN
f8Ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=feedback-id:date:message-id:content-transfer-encoding:mime-version
:subject:to:from:dkim-signature:arc-authentication-results;
bh=Y7pVjQ5emAE4pdcubLwi7473vY3OWUVV5NusExrVNc8=;
b=DlgSuorHXVeVtWhKM/csFcSeADLzJCLSuzCwZEsHVT7XLtmwSQERCwlIDHyabl8Ffa
NNXx8CCYYfrAu0mbg3vGnAvG8SmusEwfBe0cAaa7D1bGf2fM/hGJzsQX21e3rbyQzvnu
GSTZjwpW48sFkWzN863wLai5Z2Ne+eR/7lyzfEO/mIIJL0f3uvVmV32kFYMWHxYz0x8/
r8GpiLqfD6nxMqvpxn04a/KYgo97/TxyB9AFaKEN08ih1d7+qLE5isq+BJI2NjCJLHnW
vqlM1ideeygoN20cgTaz6ZQpYOQAsO0SIZQkoOtkT/6eb0DNCEa1RO45AmMgC9ZJ4rkc
PYKQ== ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=#amazonses.com header.b=WNeDQXRK;
spf=pass (google.com: domain of 0100015cd2a93eb9-85164c9c-6cfb-46ec-a985-02909a4b6b0c-000000#amazonses.com
designates 54.240.9.109 as permitted sender)
smtp.mailfrom=0100015cd2a93eb9-85164c9c-6cfb-46ec-a985-02909a4b6b0c-000000#amazonses.com
Return-Path:
<0100015cd2a93eb9-85164c9c-6cfb-46ec-a985-02909a4b6b0c-000000#amazonses.com>
Received: from a9-109.smtp-out.amazonses.com
(a9-109.smtp-out.amazonses.com. [54.240.9.109])
by mx.google.com with ESMTPS id h186si1190862qkc.200.2017.06.22.18.55.26
for
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Thu, 22 Jun 2017 18:55:26 -0700 (PDT) Received-SPF: pass (google.com: domain of
0100015cd2a93eb9-85164c9c-6cfb-46ec-a985-02909a4b6b0c-000000#amazonses.com
designates 54.240.9.109 as permitted sender) client-ip=54.240.9.109;
Authentication-Results: mx.google.com;
dkim=pass header.i=#amazonses.com header.b=WNeDQXRK;
spf=pass (google.com: domain of 0100015cd2a93eb9-85164c9c-6cfb-46ec-a985-02909a4b6b0c-000000#amazonses.com
designates 54.240.9.109 as permitted sender)
smtp.mailfrom=0100015cd2a93eb9-85164c9c-6cfb-46ec-a985-02909a4b6b0c-000000#amazonses.com
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1498182926;
h=From:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID:Date:Feedback-ID;
bh=VCZKg8hFUb63lOKDitSw+wHccKQ7iJdOqT+3v5T9kMM=;
b=WNeDQXRKVjREfsyiCHuwazQD7AXWRfZc3UcrwH1AghtaCnavxJ6CBSLTUsIqc5GF
m6/uRCDItr6crWjplYgl14Dq2mbGHMFtB+vZHh0PPNmO4n3+/8PevleQbEYInRWmlec
ZbFX57QHhrNXtEyUc4qaM3ZtjpcwjaPzOXe2liB8= From: No-Reply
To: rifaterdemsahin#gmail.com Subject:
Performance Warning(3x) IP: 192.168.30.40 Method:
Broadage.Common.Tools.Email MIME-Version: 1.0 Content-Type: text/html;
charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID:
<0100015cd2a93eb9-85164c9c-6cfb-46ec-a985-02909a4b6b0c-000000#email.amazonses.com>
Date: Fri, 23 Jun 2017 01:55:26 +0000 X-SES-Outgoing:
2017.06.23-54.240.9.109 Feedback-ID: 1.us-east-1.SIJlVA2xTbAVdBXctlUaxBDeEU1mquOgueuof7Nldbc=:AmazonSES
Performans Uyar=C4=B1s=C4=B1Mak= ine Ip =3D> 192.168.30.40Uygulama Ad=C4=B1 =3D> Method Name =3D> Broadage.Common= .Tools.Email=C4=B0stenilen Performans S=C3=BCresi =3D>
250 ms elapsed timeHarcanan S=C3=BCre=
=3D> 786.708 ms elapsed time
1) As pointed by Jordan Stewart, configure your filter to delete messages, but don't mark them as spam.
2) As complaint directly to the company did not work, I suggest complaining to AWS. See here https://aws.amazon.com/premiumsupport/knowledge-center/report-aws-abuse/
They seem to take abuse (or misuse) of their platform quite seriously. So, I would expect the company will be forced to either fix the issue or be disconnected from SES service.
I think your best option is to automatically delete the emails in the gmail, through setting up a filter. I think this page explains how to setup the filter: https://www.businessinsider.com.au/automatically-delete-unwanted-gmail-2014-1
I don't think you can interact with their setup of AWS SES. If you were able to it would be a security vulnerability of SES.
It could be possible to setup a gmail custom script that could delete the emails, but in affect it would be doing the same thing as the filter. Except the filter is easier.
I think the business sending unwanted information is probably against an anti-spam act. So what they are doing is probably illegal, or at least probably negligent.
I hope that helps.
From my understanding of AWS, this is an error that needs to be fixed from the company that is sending these emails. There is SES probation (http://docs.aws.amazon.com/ses/latest/DeveloperGuide/e-faq-sp.html). I would try emailing ses-enforcement#amazon.com and see if they can help you.
Related
If you google "How to check an email address for existence" question, you will find, basically, only solutions using SMTP protocol what is not reliable. I tried this approach and found that Gmail SMTP server says "Yes, this email is registered here" on each and every email address I ask about. I suspect such strategy is used on the majority of popular email servers.
The method I would like to share is used in Gmail registration form to ensure you are going to register a brand new email. It uses AJAX request to ask Gmail server if given email exists or not
Request URL:https://accounts.google.com/InputValidator?resource=SignUp
Request Method:POST
Status Code:200
Remote Address:173.194.222.84:443
Response Headers
alt-svc:quic=":443"; ma=2592000; v="37,36,35"
cache-control:private, max-age=0
content-encoding:gzip
content-type:application/json; charset=utf-8
date:Wed, 29 Mar 2017 21:06:06 GMT
expires:Wed, 29 Mar 2017 21:06:06 GMT
server:GSE
set-cookie:GAPS=1:<redacted>;Path=/;Expires=Fri, 29-Mar-2019 21:06:06 GMT;Secure;HttpOnly;Priority=HIGH
status:200
strict-transport-security:max-age=10893354; includeSubDomains
x-content-type-options:nosniff
x-frame-options:DENY
x-xss-protection:1; mode=block
Request Headers
Provisional headers are shown
Content-type:application/json
Origin:https://accounts.google.com
Referer:https://accounts.google.com/SignUp?hl=en-GB
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Query String Parameters
resource=SignUp
Request Payload
{"input01":{"Input":"GmailAddress","GmailAddress":"andy.v.che","FirstName":"","LastName":""},"Locale":"en-GB"}
Response
{"input01":{"Valid":"false","ErrorMessage":"Someone already has that username. Note that we ignore full stops and capitalisation in usernames. Try another?","Errors":{"GmailAddress":"Someone already has that username. Note that we ignore full stops and capitalisation in usernames. Try another?"},"ErrorData":["andyvche959"]},"Locale":"en_GB"}
As you can see, there is "Valid":"false" in the response if such an email does exist, and (spoilers) "Valid":"true" if it doesn't.
Throttling queries down
Guys from Gmail do understand this method could be used by spammers to look for existing emails. That's why they don't allow massive scans using it. I was doing such a scan for some time and could scan only 200 emails a day approximately.
More details
I was scanning 1 email a minute, and if I was getting response "No, this email doesn't exist", I also asked if my own email exists. If I got "No, your email doesn't exist as well" answer, I could clearly understand that I got ban from Gmail server by my IP address. Then, I took a break for 45 minutes to get unbanned, then continued the loop. The number af emails scanned a day was fluctuating around 200.
You may ask: you did a scan like a spammer would perform, for what purpose did you do that scan then?
My answer is: I was trying to find a guy who wrote his email unclearly (bad cursive). There was no other option to find him.
There were 3 unclear letters in his written email but it was clear the domain of it is gmail.com, so I came up with an idea to find a way to check an email address for existence on Gmail, generate a list of all possible emails (trying to substitute unknown symbols with all possible English letters) and check them all for existence. Then, send a letter to all existing ones.
The right of this information to be published is discussed in this question. I understand this article will be very useful for spammers so I'm open to deleting it partially or even completely for the sake of security.
I tried to install ReadTheDocs on my linux server following the documentation: http://read-the-docs.readthedocs.io/en/latest/install.html
However I do not receive the activation email.
I was able to see the output of the email on the server
Hello from example.com!
You're receiving this e-mail because you or someone else has requested a password for your user account at example.com.
It can be safely ignored if you did not request a password reset. Click the link below to reset your password.
http://xxxxx:8080/accounts/password/reset/key/xxxxxxxxxx/
In case you forgot, your username is xxxxxxxxxxxx.
Thank you for using example.com!
example.com
note: This email is a password reset email, it has the same problem as the activation email. (I didn't receive any email from my ReadTheDocs installation)
There are two things that got my attention.
1. Where does read the docs configure the website name, I would like to change example.com to th real website name.
2. The sending adres currently is no-reply#readthedocs.org, where can I change it? I think its also a part of the issue.
Here are the other headers of the email
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: [example.com] Password Reset E-mail
From: no-reply#readthedocs.org
To: xxx#xxxxx.nl
Date: Tue, 12 Jul 2016 11:30:49 -0000
So actually I have two questions
Where can I change the content of the email and things like the sender adres.
What happend with the email (why won't I receive it)
Am using phpmailer to send email from my Gmail account.
Gmail is not delivering emails if I have a link in message body. Here is my email
Dear Zeeshan,
Thank you again for calling Test. We improve our service based on your feedback. Will you please rate your experience to let us know how we did? Click on the link below!
Click Here to Share Your Review
If I remove the link, email works fine. What is issue with this link?
Here is what gmail send me back
Delivery to the following recipient failed permanently:
shah.zeshan#gmail.com
Technical details of permanent failure:
Message rejected. See https://support.google.com/mail/answer/69585 for more information.
----- Original message -----
X-Received: by 10.202.67.133 with SMTP id q127mr3207265oia.116.1455592533646;
Mon, 15 Feb 2016 19:15:33 -0800 (PST)
Return-Path: <lockandtowservice#gmail.com>
Received: from rsasatisfaction.com (rs43.whbdns.com. [209.105.241.194])
by smtp.gmail.com with ESMTPSA id pp10sm17110856obc.16.2016.02.15.19.15.32
for <shah.zeshan#gmail.com>
(version=TLSv1/SSLv3 cipher=OTHER);
Mon, 15 Feb 2016 19:15:32 -0800 (PST)
Date: Tue, 16 Feb 2016 03:15:31 +0000
Return-Path: lockandtowservice#gmail.com
To: shah.zeshan#gmail.com
From: Test <lockandtowservice#gmail.com>
Subject: Share Your Review For Test
Message-ID: <5b7609c465e4ebe2ef057cc7f0db582f#rsasatisfaction.com>
X-Priority: 3
X-Mailer: PHPMailer 5.2 (http://code.google.com/a/apache-extras.org/p/phpmailer/)
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="b1_5b7609c465e4ebe2ef057cc7f0db582f"
<p>
Dear Zeeshan,
</p>
<p>
Thank you again for calling Test. We improve our
service based on your feedback. Will you please
rate your experience to let us know how we did?
Click on the link below!
</p>
<p>
<a
href="http://rsasatisfaction.com/home/feedback/57/1/Zeeshan/shah.zeshan#gmail.com">Click
Here to Share Your Review</a>
</p>
<p>
Thank you again. If we can be of more service,
please let us know.
</p>
<p>
Warm regards,<br>
Test<br>
</p>
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
We use Mailgun to send out emails and recently I noticed quite a few emails each day are being rejected by Gmail.
Here's the type of message we receive:
550
5.7.1 [184.173.153.6 11] Our system has detected that this message is
5.7.1 not RFC 2822 compliant. To reduce the amount of spam sent to Gmail,
5.7.1 this message has been blocked. Please review
5.7.1 RFC 2822 specifications for more information. f15si23385851vdu.1 - gsmtp
The RFC 2822 spec is a massive document so I haven't read it front-to-back but from looking at resources around the web our emails don't fall into any of the common pitfalls that would trigger this type of response from Gmail.
Here's an example email header:
Received: by luna.mailgun.net with HTTP; Mon, 29 Jun 2015 21:06:59 +0000
Message-Id: <20150629210659.18668.39318#(domain)>
X-Mailgun-Variables: {"variation": "original", "campaign_code":
"(customValue)"}
Reply-To: (name) <(email)>
X-Mailgun-Track: false
X-Mailgun-Tag: (customTag)
To: (email)
From: (name) <(email)>
Subject: (subject)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="12f0bd630f2145a3afcd98b621a3b1f2"
--12f0bd630f2145a3afcd98b621a3b1f2
Content-Type: text/plain; charset="ascii"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
(text content)
--12f0bd630f2145a3afcd98b621a3b1f2
Content-Type: text/html; charset="ascii"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>(title)</title>
<style type="text/css">
(css)
</style>
</head><body style="(css)" >
(content)
</body>
</html>
--12f0bd630f2145a3afcd98b621a3b1f2--
What are we doing wrong?
One obvious rfc2822 violation in your example is the missing Date header .
from rfc2822, Section 3.6:
The only required header fields are the origination date field and
the originator address field(s).
It turned out we were using two different domains for the From and Reply-to which I guess is a no-no.
Is it alright to send HTML-only emails without the text/plain part when doing HTML only actions like clicking a link to view replies or some other "alert" type notification? For example, clicking a link to activate your email or clicking to see new comments.
Date: Wed, 07 Mar 2012 10:30:54 -0800 (PST)
From: email#site.com
Subject: Test Mail
To: <email#site.com>
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
VGhpcyBpcyBdfJDFKdjfkdsFpbCBmcm9tIGxvY2FsaG9zdCB3aXRoIGZzbdrb3BlbigpIGF0IDEz
eGVvbmNyb3NzLmNvbSI+eGVvbmNyb3NzLmNvbTwvYT4gPGk+bGluazwvaT4hPHA+VGhpcyBpcyBt
b3JlIHRleHQ8L3A+
Instead of using multipart to create two copies of the same email.
Date: Wed, 07 Mar 2012 10:30:54 -0800 (PST)
From: email#site.com
Subject: Test Mail
To: <email#site.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="4f57a7d259baf"
--4f57a7d259baf
Content-Type: text/html; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: base64
VGhpcyBpcyBdfJDFKdjfkdsFpbCBmcm9tIGxvY2FsaG9zdCB3aXRoIGZzbdrb3BlbigpIGF0IDEz
eGVvbmNyb3NzLmNvbSI+eGVvbmNyb3NzLmNvbTwvYT4gPGk+bGluazwvaT4hPHA+VGhpcyBpcyBt
b3JlIHRleHQ8L3A+
--4f57a7d259baf
Content-Type: text/text; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: base64
VGhpcyBpcyBdfJDFKdjfkdsFpbCBmcm9tIGxvY2FsaG9zdCB3aXRoIGZzbdrb3BlbigpIGF0IDEz
MzExNDQ2NTgKCkFsc28gd2l0aCBhIGdvb2dsZS5jb20gdXJsIGFuZCB4ZW9uY3Jvc3MuY29tIGxp
bmshVGhpcyBpcyBtb3JlIHRleHQ=
I would like to save the bandwidth if there isn't a very good reason to include the text version.
If you're looking to save bandwidth, I don't think you should be using base64 encoding as it makes your data 33% larger (on average). In my understanding, text/plain (not text/text) should always be provided in a human-readable format (like quoted-printable).
I don't think there are many e-mail clients that can't read HTML nowadays, still I think your decision should reflect how important it is for the end-user to be able to read (and understand) your e-mail / alert and not (minor) bandwidth limitations. I've no experience with AOL, but I think it had some issues with e-mail links a few years ago, perhaps that counts as a bonus points for the plain text alternative.
Also, don't forget that the actual links need to be displayed in plain text versions.