0

Suppose I register an Email address on Gmail for instance. I verify my address(not domain) in Amazon Simple Email Service. Then I send emails using Amazon from this address.

Who actually does the sending? Amazon or Gmail? How can Amazon connect to Gmail and any other Email service when there are so many of them? Does Gmail expose some API conforming to some protocol so it allows to use its own addresses?

Or does Amazon just do everything on its own and pretends to be Gmail? If so then what prevents me from deploying my own Email server and pretending to be somebody@gmail.com without verification?

UPDATE: It seems I failed to articulate my question properly. If I spoof the from field the recipient will ban me. Amazon is not banned. Why? I thought that maybe there is some tricky technical solution that prevents it from being banned. Is it just nothing but Amazon's reputation? Did Amazon just arrange that by verbal negotiation with the mail services? This is not obvious. Is verifying only an address a good enough practice? Or is it indeed not reliable enough? Amazon docs don't mention that it's unreliable. Isn't it important?

Gherman
  • 145
  • 6
  • I don't know exact answer for your Question. But I know Gmail has Api. Anyone can use it. For more details refer below link. https://developers.google.com/gmail/api/guides/sending – serverAdmin123 Feb 06 '19 at 09:37
  • @serverAdmin123 But a different Email service may not have such api. Or may have a different api. This api seems Gmail-specific. – Gherman Feb 06 '19 at 09:59
  • 3
    The mail is sent using Amazons own mail servers and the level at which Amazon can appear as the domain your email address belongs to depends on the level of authentication / domain configuration you can do. For a Gmail account you can only show ownership of your mailbox, and messages will behave somewhat like *"Amazon sent this message on behalf of "example AT gmail.com - please send replies directly to that address""* but with with your own domain you can set up DKIM, DMARC, SPF and other advanced authentication. Then Amazon can almost disappear and completely assume your email identity. – HBruijn Feb 06 '19 at 10:06
  • @HBruijn I am specifically asking about email address and not domain verification. If Amazon just pretends to be Gmail then what prevents others from impersonating Gmail accounts without verification? – Gherman Feb 06 '19 at 10:22
  • What is wrong about my question that it gets minuses? – Gherman Feb 06 '19 at 20:33
  • @Gherman Nothing prevents it. You can do it, right now. The fact that the sender doesn't line up with Gmail's SPF record will likely give it substantial spam points - and this is the case if you send from Amazon SES as a Gmail address, as well. – ceejayoz Feb 07 '19 at 01:25

3 Answers3

8

Emails are sent using the SMTP Protocol that originates in the early 80’s. Back in those days everyone connected to The Internet pretty much trusted each other, it was very much an academic / research network. Hence, thanks to these origins, the SMTP protocol provides virtualy no protection against the current threats - spam, phishing, viruses, identity theft, etc. Like with many other protocols from that era that still make the foundations of todays internet (DNS, HTTP, BGP, etc.) the authors of these protocols didn’t expect that anyone would try to abuse them and they didn’t build in any protections.

Therefore with plain SMTP I can send you an email appearing to come from your gmail addres, from president@whitehouse.gov or from any other address I choose. SMTP itself allows that, and SES uses SMTP. Of course because that’s the email protocol.

Indeed, that can easily be abused - that’s why over time some protections have been developed: DKIM, SPF, and others. However these are optional and depend on proper configuration both by the domain owner and at the recipient side. You would be surprised how many domains are completely unprotected.

So to wrap up - Amazon SES sends emails through SMTP protocol and like any other SMTP server can “impersonate” any sender address they like.

Obviously they won’t give you a completely free ride so before they send out any emails on your behalf you must prove that you control the sender address or domain. But that’s purely a policy imposed by Amazon, technically they could use any sender address if they wanted.

On the other hand: sending as something@gmail.com through SES may not be 100% reliable because gmail.com has SPF and DKIM configured and AWS SES can’t spoof these protections. But that’s on top of SMTP and it must be supported by the recipient too. If the recipient doesn’t check DKIM and SPF the email will get through.

Also - the sender IP address reputation matters. Any personal SMTP server will probably have a worse IP addr reputation than a massive, trusted service like SES.

All these factors contribute to spam score. If everything else (incl. the IP rep) says it’s not a spam a failed SPF check probably won’t tip it over. That's why your “technically invalid” email from SES gets through - because everything else but SPF seems to be OK. Spam assessment is a complex topic.

For the best results use your own domain as a sender and configure its SPF record to include / permit sending from SES servers.

Hope that explains it :)

MLu
  • 23,798
  • 5
  • 54
  • 81
  • "AWS SES can’t spoof these protections" -- this is the exact thing I do not understand! If I deploy an SMPT-server and try to impersonate somebody _the recipient will ban me as spam!_. Yet Amazon is not banned even though it has nothing to do with the domain(in case it is verified solely with address). How can Amazon do that and get away from being banned? I mean you say it can't yet it somehow does. – Gherman Feb 07 '19 at 00:16
  • @Gherman Depending on the recipient configuration the SPF or DKIM failure may be ignored (common), or classified as outright spam (not common), or contribute towards spam score (very common). Also sender IP reputation comes to play - your own server’s IP is presumably less “trustworthy” than SES IPs’. All these factors contribute to spam score. If everything else says it’s not a spam a failed SPF check probably won’t tip it over. Spam assesment is a complex topic. – MLu Feb 07 '19 at 01:18
  • @Gherman Amazon SES likely has a better reputation than you do. I've seen plenty of SES mail go to spam, incidentally. You seem to be confusing individual emails being marked as spam with IP or domain-wide blacklisting, which a significantly more severe penalty. – ceejayoz Feb 07 '19 at 01:26
  • @MLu please add to the answer that reputation of ips comes to play on SPF/DKIM failure. This is what I was asking about. Without that the picture is not complete. – Gherman Feb 07 '19 at 08:59
  • @Gherman no prob, updated the answer. – MLu Feb 07 '19 at 12:29
  • @Gherman Reputation doesn't come into play with SPF/DKIM failure. Reputation always comes into play, but it has nothing to do with SPF/DKIM. It's just another metric that goes into the total spam score. Think of it like this sort of calculation: Passed SPF - five points! Valid DKIM signing - 10 points! Uh oh, the IP address sends spam a lot... minus 25 points! – ceejayoz Feb 07 '19 at 15:53
  • @ceejayoz Can't you understand that I am talking about one real life scenario and not theory? We have SPF/DKIM failure. And we have Amazon SES. And somehow it works(is not banned). Who cares how protocols are designed? I did not ask how SMTP works. I asked why it works when I know it normally doesn't. Read the question. It does not mention SMTP and SPF. You can spoof sender in imaginary SMTP. But you can't do it in real life. Everybody bans that. Hence the question. This is why I can _conclude_ that "on SPF failure reputation may still outweigh it". And it is not wrong because it's real. – Gherman Feb 07 '19 at 16:13
  • 3
    What you're fundamentally missing is that a spam score is based on dozens/hundreds/thousands of potential data points, including black-box machine learning algorithms not fully understood even by the folks who coded it. Raw SMTP trivially permits spoofing; SPF and DKIM are (imperfect) mitigation measures. Different email providers will handle SPF or DKIM failures (or absences, or passes) in different manners. Ultimately, if you want your emails reliably delivered, you should only send from a server that's authorized via SPF for the domain. – ceejayoz Feb 07 '19 at 16:19
  • @ceejayoz Thanks for clarification. Now I understand what you want to say. – Gherman Feb 07 '19 at 16:38
2

The confusion here is caused by failing to take into account the distinction between the envelope-from (sometimes called "MAIL FROM") and the header-from (sometimes called From:).

SPF only applies to the envelope-from. You can see the details in the documentation. There are two setups. One requires you to own the domain so it doesn't apply to you. You use the other setup:

...use the default MAIL FROM domain of Amazon SES, and to not publish an SPF record at all. This setup enables you to pass an SPF check because by default, Amazon SES uses its own MAIL FROM domain to send your emails.

Now, this completely covers SPF. However, as noted spam detectors do much more analysis, including examining headers so your mail could still be considered spam.

Mark Wagner
  • 17,764
  • 2
  • 30
  • 47
2

Too long to comment, but to re-iterate and expand on my earlier comment: the message will people will receive will, under the hood, look like "Amazon sent this message on behalf of "example AT gmail.com - please send replies directly to that address" and Amazon does not have to spoof anything as it is not pretending to be gmail, or any other domain, as far as SMTP is concerned the message will be from an Amazon domain.

Just like snail mail letters, SMTP email has two different sets of address information: the envelope headers (like the addresses printed on the outside of an envelope) which are used by the SMTP servers to route and deliver the email, and the "normal" headers, which are part of the mail message and which are only read and interpreted by the user in his mail client/webmail, just like the address attached to a salutation at the start of a physical letter. Unlike the post office, SMTP usually throws away most of the envelope before it hands the message to the user.

On the SMTP envelope Amazon will use their own domain and a unique mailbox name on their domain that maps to your account.

In the mail message will be a From: and a Reply-To: header with your Gmail address, but a Return-Path: with the Amazon address.

Because the envelope sender is an Amazon domain and the SPF records that will be used will be for the envelope sender, the message will pass SPF checks. 1 Because the SPF checks are passed odds are then much higher that the message will then be delivered.

(And Amazon may also add a DKIM signature for/from their own domain to the message, increasing their delivery odds. The signature won't be aligned correctly though. )

A simple telnet mail session might illustrate this better:

[user@amazon ~]$ telnet gmail-smtp-in.l.google.com 25
Trying  74.125.128.27...
Connected to localhost.
Escape character is '^]'.

<<< 220 mx.google.com ESMTP 

helo Amazon

<<< 250 mx.google.com Hello Amazon [127.0.0.1], pleased to meet you

MAIL FROM:uuid@Aamzon

<<< 250 2.1.0 uuid@Amazon... Sender ok

RCPT TO:user@gmail.com

<<< 250 2.1.5 user@gmail.com... Recipient ok

DATA

<<< 354 Enter mail, end with "." on a line by itself


Subject: test
From: somebody@gmail.com
Reply-To: somebody
To: user@gmail.com
Return-Path: uuid@Amazon
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=Amazon

this is the email message you will see in your mailbox.
It has two lines and will appear to be from **somebody@gmail.com**.
.
<<< 250 2.0.0 t6HITQXA020072 Message accepted for delivery
quit
HBruijn
  • 72,524
  • 21
  • 127
  • 192
  • So it's reliable enough with just address? Is accepted answer wrong? – Gherman Feb 08 '19 at 15:47
  • I although I think that SES makes better effort than you would expect from [Mlu's answer](https://serverfault.com/a/952695/37681) I completely agree with the statements made there that *"sending as something@gmail.com through SES may not be 100% reliable"* and *"for the **best results** use **your own domain**"* – HBruijn Feb 08 '19 at 15:54