[HN Gopher] Google spoofed via DKIM replay attack: A technical b...
___________________________________________________________________
Google spoofed via DKIM replay attack: A technical breakdown
Author : frasermarlow
Score : 268 points
Date : 2025-07-25 05:28 UTC (17 hours ago)
(HTM) web link (easydmarc.com)
(TXT) w3m dump (easydmarc.com)
| userbinator wrote:
| _Step 3: Attacker sends the email from Outlook_
|
| AFAIK you can't spoof the path listed in the Received: headers as
| all the servers on the path will add their own. That's always
| been my way of verifying where emails come from, and it's
| reassuring to know that I would've caught this one too. Emails
| coming from Google aren't going to take a detour through
| Microsoft servers.
| emsixteen wrote:
| I'm going to go out on a limb and guess you don't manually
| check the headers for every single email, or even only every
| one from Google and co, so are you doing something to flag or
| visualise this in some way?
| tharkun__ wrote:
| I'm with the person you are replying to here.
|
| Whenever I get an email that seems like it's a scam or scary
| like this I will open headers and the Received headers
| (sometimes even a From et. al. are enough) will give it away.
|
| In zero cases did I care about SPF, DMARC or DKIM.
|
| I recognize that this is not something non technical people
| or even technical people that don't know how email works and
| that don't have a broader technical ability/knowledge can
| usually use/do but it has worked 100% for me so far. _knocks
| on wood_.
|
| I literally only skimmed the article looking for any place
| they might show all headers and finally when they had the
| list of Received I was like: duuuh, that's the first you
| should have looked at and this would be a non blog.
|
| So of course it's still bad this happens as most folks, even
| technical ones, couldn't read email headers to save their
| lives and rely on little badges and filters based on things
| like DKIM to keep them safe.
| userbinator wrote:
| The sibling comment basically answered for me; I don't check
| the headers unless I'm feeling suspicious, and such an
| immediate urgent call-to-action definitely counts as
| suspicious.
|
| It helps that I'm using a client which shows all the headers
| by default, and I normally just scroll past them if I don't
| have doubts; all the mainstream consumerist ones seem to make
| that very difficult or even impossible.
|
| If anything, it seems hiding these details is a way to
| increase blind trust in things like DKIM and promote learned
| helplessness, so they have the incentive to make clients
| opaque.
| KevinMS wrote:
| You cant spoof the header of the last _trusted_ server, that 's
| it.
| logifail wrote:
| The author writes:
|
| > "Here is the URL from that email [..]
| https://sites.google.com[...]"
|
| THAT link is the first red flag, and I think the author should
| say so _right there_ , not three paragraphs later.
| seszett wrote:
| No, you can't expect everyone to know about every subdomain of
| google.com.
|
| I think the real failure here (besides the unlimited field in
| the SSO) is Google allowing user content under a subdomain of
| their main domain (and there might be others, like Drive).
| asimpletune wrote:
| The main failure is that dkim still passed even though the
| email was modified in important ways.
| seszett wrote:
| Well there are a few different big failures, from not
| signing the To: to allowing long arbitrary content in an
| email sent from a legitimate Google address...
|
| But I think Google sites is the most important one because
| it makes sites look like they are actually Google wherever
| one comes from, it could be a pop-under loaded by another
| site or whatever, I think it's a more universal avenue for
| phishing than just exploiting DKIM.
| aaronmdjones wrote:
| The To header was included in the DKIM signature. The
| reproduction section of the article shows the result of
| final delivery to the victim which shows the original To
| header. If that were removed it would invalidate the
| signature.
| aaronmdjones wrote:
| The body of the e-mail was not modified whatsoever. Nor
| were any of the signed headers of the e-mail, including the
| Subject, From, and To headers.
| iwontberude wrote:
| This criticism is not for everyone, it's for us, the audience
| on HN that want novel stuff that is more hard than this. This
| is boring.
| pbhjpbhj wrote:
| There have been a few exploits over the years relying on
| sites.google.com because of the need to use a subdomain to
| make things work for the exploiters.
|
| I don't think I've ever seen Google advertise Sites either?
| Why not GoogleSites.com?
| michaelmior wrote:
| > I think the real failure here (besides the unlimited field
| in the SSO) is Google allowing user content under a subdomain
| of their main domain (and there might be others, like Drive).
|
| IIRC, this is the main reason GitHub moved Pages to github.io
| michaelt wrote:
| The other reason is: If a user figures out a way to upload
| javascript and have it work, you don't want them to steal
| other users' login cookies.
|
| This is why your gmail attachments should show up on
| googleusercontent.com instead of google.com
|
| Many years ago, some naive websites would let users upload
| images, but wouldn't validate their content; and some
| browsers would ignore file content type headers if they had
| a better guess. So an attacker could rename a .html to a
| .jpg, upload it as your user profile image, then direct
| people to www.example.com/avatars/eviluser.jpg and they'd
| get a HTML page and run its javascript.
|
| That's why, to this day, you sometimes see websites sending
| the header "X-Content-Type-Options: nosniff" which tells
| Internet Explorer 8 not to guess the content type.
| aaronmdjones wrote:
| > The other reason is: If a user figures out a way to
| upload javascript and have it work, you don't want them
| to steal other users' login cookies.
|
| This was solved a long time ago by marking such cookies
| as "HTTP only", preventing client-side scripts from
| reading their values.
|
| Google does mark their account login cookies as both
| "Secure" (sent only over HTTPS) and "HttpOnly" (not
| exposed to client-side scripting). You can see this in
| the server response headers in the browser dev tools'
| network tab. Even a piece of first-party JavaScript
| loaded directly from google.com -- even with SRI --
| cannot read these cookies for google.com.
| michaelt wrote:
| _> This was solved a long time ago by marking such
| cookies as "HTTP only"_
|
| That stops the attacker from exfiltrating your cookies
| with their evil JavaScript - but they can still have
| their script make http requests, and they'll be made with
| your cookies.
|
| Or they can throw up a fake login page, which will fool
| plenty of users because it's on the right URL, and do
| what they like with your inputs. Lots of attack options.
| EE84M3i wrote:
| SVGs are also images that can contain scripts if not
| validated.
|
| It's also relevant that github.io is on the public suffic
| list, which impacts a bunch of downstream things and
| isolates the subdomains from each other.
| fc417fc802 wrote:
| > if not validated
|
| I thought script tags were an official part of SVG?
| Meaning that a valid SVG can contain embedded JS.
| bandie91 wrote:
| he must have meant to 'sanitize' or 'filter'
| tmdetect wrote:
| A red flag for you yes, but your parents?
| shenbomo wrote:
| Why DKIM signature doesn't include the content of the email too?
| asimpletune wrote:
| I don't think the content was modified. If it had been then the
| signature would have been invalidated. The attacker found a way
| to send themself an email from Google that the author later
| replicated using Google workspace + a Google OAuth app. Then
| they replayed that because Google isn't signing the "to" field.
| jorams wrote:
| > Then they replayed that because Google isn't signing the
| "to" field.
|
| Google _is_ signing the To field (at least on all email they
| send me). The attacker didn 't change that either, as
| displayed in the screenshots in the article. The attacker
| took an email legitimately sent from Google to them, then
| redirected it to the victim.
|
| An equivalent real-world mail scenario would be me taking a
| letter from my bank to me, putting it in a new envelope, then
| sending it to you. Then your assistant takes it out of the
| envelope and puts it into your inbox. The letter in _your_
| inbox is a completely valid letter from said bank, intended
| for _me_.
|
| There's two things in this article Google does badly:
| Allowing free input of an app name and putting it directly at
| the top of an email they send without preceding it with an
| indication what the email is about, and hosting user-managed
| websites on a subdomain of google.com.
| seszett wrote:
| It does. It's not obvious from the writing but Google actually
| sent this email to the attacker (which then redirected it
| mostly unchanged except for the To: header).
|
| The main content of the email is text used for the "App Name"
| field of the attacker's OAuth app. This explains why the
| screenshot of the email actually does look weird, with unlinked
| URLs and weird formatting.
|
| I'm pretty sure there is a lot more at the end of the email
| that makes it obvious it's not legitimate. But then I also
| understand how quite a few people wouldn't even get to the end.
| aaronmdjones wrote:
| The attacker did not change the To: header. This would
| invalidate the DKIM signature and result in a DMARC fail and
| the message landing in Spam (or being rejected).
|
| You can receive e-mail with a To: header saying anything. It
| doesn't have to be you.
| asimpletune wrote:
| This is terrifying. Imagine trying to explain to a relative the
| lesson of this post: always be suspicious, even if the email is
| from a trusted domain and dkim/dmarc/spf all pass... it doesn't
| feel good to imagine their reaction.
|
| This is still limited in what you can do though. For example you
| can't use this to forge messages from other people's Gmail
| accounts.
|
| > When the message is forwarded, the original DKIM signature
| usually remains untouched as long as the email content and
| headers covered by the signature are not modified
|
| It does seem surprising the To: header isn't one of the headers
| that is covered by the dkim signature. They should just change
| how their signing is configured, and email clients should warn
| when the email is legit but the intended recipient could have
| been changed.
| JoshTriplett wrote:
| > always be suspicious, even if the email is from a trusted
| domain and dkim/dmarc/spf all pass
|
| This was the default state of email for a long time, and is
| still the level of caution some people apply to email: never
| trust `From`.
| globular-toast wrote:
| I've blown people's minds by spoofing "From" before. It's
| amazing the completely unwarranted level of trust people have
| in things. I tell people it's no different from me typing up
| a letter and putting "love from Mum" at the bottom.
|
| I blame shiny email clients like Outhouse etc. It's really
| dangerous to make something _look_ like a better system than
| it is. If email were still viewed as plain text I don 't
| think it would be seen the same.
| bawolff wrote:
| Note, you can't forge the from header if DMARC is turned
| on. The From header was not forged in the article afaict.
|
| It doesnt really matter because email clients usually dont
| even show the email part of the from header.
| JoshTriplett wrote:
| > email clients usually dont even show the email part of
| the from header.
|
| Good email clients _should_ , though.
| Biganon wrote:
| Isn't it also SPF's role to check that the From domain is
| allowed for the sender IP ?
| bawolff wrote:
| No. (If you mean the from header)
|
| SPF (without dmarc) validates the envelope from, not the
| from header.
|
| When DMARC is present, it changes this to be the normal
| from header (dmarc requires one of either spf or dkim to
| match the from header. So if dkim matches then spf
| doesn't have to)
| bawolff wrote:
| > Imagine trying to explain to a relative the lesson of this
| post: always be suspicious, even if the email is from a trusted
| domain and dkim/dmarc/spf all pass
|
| Imagine explaining to a relative what dkim/dmarc/spf is!
|
| These are all behind the scenes technology that users should
| not be aware of.
|
| Honestly this attack is not as scary as it sounds. The article
| is being misleading to sell their product.
|
| > It does seem surprising the To: header isn't one of the
| headers that is covered by the dkim signature.
|
| I dont think that would really matter. How often do you read
| the To header. Keep in mind that in email the To header does
| not have to include the intended recipient.
| fc417fc802 wrote:
| > How often do you read the To header. Keep in mind that in
| email the To header does not have to include the intended
| recipient.
|
| Perhaps if the address at which you received the email does
| not match any which are covered by the DKIM signature then
| your client could warn you about the potential for foul play?
| bawolff wrote:
| I don't think that would be a good idea. The false positive
| rate would be too high and i don't think forging the to
| header is useful enough to phishing to make it worth it.
| salawat wrote:
| >These are all behind the scenes technology that users should
| not be aware of.
|
| Every time I hear this statement, alarm bells ring in my
| head. We aren't immortal. None of us is omniscient, and
| unfortunately the bad actors we're trying to protect against
| obviously don't give two shits about getting their hands
| dirty. We can't just hide all implementation details from
| users, especially when today's users may of necessity become
| tomorrow's admins.
| aaronmdjones wrote:
| > It does seem surprising the To: header isn't one of the
| headers that is covered by the dkim signature
|
| It is, which is why they had to preserve it. The screenshot of
| delivery under the reproduction section shows the original To:
| address. This isn't the address that it is delivered to; you
| can deliver an email to any address with any other To: field in
| it.
| tmdetect wrote:
| My advice here is pretty standard: If you get an email that
| requires an action, go to the website directly. Don't click any
| links.
|
| It adds friction, but does solve the problem. For
| banking/systems, I'd much rather have the friction.
| rvnx wrote:
| The people who found this exploit are very smart, and the
| phishing is really convincing + would pass most of the strictest
| corporate filters
| bawolff wrote:
| They could have just read the RFC. DKIM was made specificly to
| allow this sort of thing for back compat. Its not a new attack.
| logicallee wrote:
| Edit:
|
| It seems the issue is that the to: field is signed, but the whole
| email can be forwarded afterward as though it were being sent
| from the source server to a person who wasn't actually a
| recipient.
|
| In this case Google really did send an email to the strange
| domain, which then forwarded it to the recipient and made it seem
| as though it was coming from Google's server directly to the
| recipient.
|
| This works as long as the recipient doesn't realize that they are
| not in the "to:" field.
| mzajc wrote:
| > This means you can just copy a server's signature from a
| piece of mail it signed onto another piece of mail that it
| didn't send, and it will still look like it's been signed by
| the server and coming from that server.
|
| DKIM signs both body and select headers. Unless those match,
| the signature verification will fail. TFA is about a replay
| attack.
| logicallee wrote:
| Edit: thanks for the clarification.
| mzajc wrote:
| DKIM doesn't decide which headers are signed, the mail
| server does (in the h= field). Gmail signs both To and
| From[0], but these don't control the 'real' recipient - the
| RCPT TO command in SMTP does. The recipient would
| presumably show wrong in the mail client, but since mailing
| lists and aliases are a thing, this is not suspicious by
| default.
|
| [0] h=to:subject:message-id:date:from:mime-
| version:from:to:cc:subject :date:message-id:reply-to;
| brongondwana wrote:
| Sadly, BCC is still a real thing, so the recipient system can't
| reliably tell that the recipient wasn't in the "to:" field and
| drop the message. That's one of the authentication holes that
| DKIM2 is planning to fix.
| judge123 wrote:
| Okay, the technical breakdown is wild. But my first thought was:
| how on earth do I explain this risk to my non-technical boss or
| clients? If I say 'they can bypass DKIM with a replay attack,'
| their eyes will just glaze over. We need a simple, powerful way
| to communicate this stuff. Anyone have a good one-liner for this?
| oefrha wrote:
| The one-liner is "emails you receive may be forwarded". Article
| is really confusing and oversells the attack. See my other
| comment https://news.ycombinator.com/item?id=44680400.
| monospacegames wrote:
| "Read the full email before freaking out" would probably be
| appropriate. This article is deceptive because it does not show
| the full email and only shows the phishing part. The full email
| is definitely in the format "scary text here" "actual google
| message", so something like "Give us all your money or die has
| been created as a google app", which would raise an eyebrow
| even in the most non-technical person.
| nicman23 wrote:
| flag forwarded mails?
| oefrha wrote:
| This is a very confusing read. It gives the impression that the
| attacker managed to manipulate the email body to insert their
| phishing link, by talking at length about how the
| sites.google.com link is suspicious (of course it is, no doubt
| about that). But at the same time, they don't say or show
| evidence that the body was manipulated; in fact quite the
| opposite.
|
| My understanding is that the DKIM signature contains a bh= field
| with a hash of the email body. While you can technically also
| include an optional I= field to limit the body length for
| hashing, so that an attacker can append to the body, which is a
| pretty big security hole, it's probably never used by Google for
| such short emails (I checked some of my own emails from no-
| reply@accounts.google.com and they certainly don't have I=).
| Therefore to pass DKIM and DMARC the body had to be intact, so
| the "phishing link" was actually from Google, just intended for a
| different recipient.
|
| If my analysis is correct then TFA really is a lot of words to
| say a scary email was forwarded to wrong people to scare them.
| Scary of course, but much less scary than the "DKIM replay
| attack" title implies to technical people who are not deep into
| this subject.
|
| Edit: Oh, I thought "The Takeaway?" was the end of TFA since it
| had CTA for their product. Apparently there's an update below
| explaining the link was actually part of a Google OAuth app name
| which was then inserted into Google's email template. Terrible
| writing and structuring of the article, burying arguably the most
| important part of the attack that made it somewhat convincing,
| and misleading readers to believe the attack can be used to send
| arbitrary content.
|
| Edit 2: Other commenters pointed out that the screenshot of the
| email is conveniently cut off so the fixed part of the Google
| email template isn't shown. The attack is probably even more
| clumsy then it seems from the quite deceptive crop.
| monospacegames wrote:
| I agree, the article is intentionally deceptive. It's written
| to make people think the part of the mail shown in the image is
| the whole email when in reality it's definitely followed by
| some text that would raise suspicion in any person.
| notepad0x90 wrote:
| Most people, even those looking out for something suspicious
| will let their guard down once they are convinced it is from
| a trusted and known source.
| atoav wrote:
| > some text that would raise suspicion in any person
|
| As someone who worked in IT-support I have to say this
| sentence is doing _a lot_ of heavy lifting. I have seen
| people click on shadier things that looked much less
| credible. In fact I have seen the same people do it multiple
| times, even after it has been explained to them, multiple
| times and they have experienced consequences in the form of
| locked accounrs and the likes.
|
| Real world users can be magnitudes dumber than you think they
| would be, even if they otherwise simulate the appearance of
| functional adults.
|
| I have seen people who have a problem click away error
| dialogues with the explaination of the problem without
| reading the text. When asking what they clicked and why, they
| couldn't tell you if their life depended on it.
| monospacegames wrote:
| Yes, but my point is that the article is constructed in a
| way that deliberately obfuscates that there is unrelated
| text following the phishing message (quoting my initial
| comment: The full email is definitely in the format "scary
| text here" "actual google message", so something like "Give
| us all your money or die has been created as a google app")
|
| This led to the initial response here being quite frantic
| (some people even claiming that DKIM is now pointless)
| because presumably not everyone read the article to its
| very end where the actual explanation is, and then went
| back to the first image to realize that the author has been
| intentionally misleading to sell their cybersecurity
| services.
| dylnuge wrote:
| And from what they do show, it doesn't look like the
| sites.google.com link was actually clickable, which will
| reduce the success rate of the attack substantially. I'm not
| sure if it's not clickable because the OAuth App Title field
| that the phishing contents is put in won't produce clickable
| URLs, because the email itself has been flagged by Gmail as
| suspicious and disabled links, or possibly both.
|
| From what we do see we can also clearly see the "forwarded
| message" details are present at the top of the email. Then
| the author writes that the email has "no typos" while
| ignoring that it has very suspicious formatting. It's still
| likely people will fall for it, but the article author
| clearly is being deceptive about how sophisticated this
| attack actually appears.
| bootsmann wrote:
| Yeah from what I understand the DKIM is checking out because
| they are literally forwarding an actual email they got from
| Google. The real attack vector is being able to coerce Google
| to send you an email whose text you control.
| moongoose wrote:
| The screenshot looks too real, something is off. Anything hosted
| on Google Sites has a huge Cookie Banner and an (i)-Info Icon to
| report abuse.
|
| I guess they edited the screenshot.
| sksrbWgbfK wrote:
| They may have changed the screenshots but I confirm that I
| received the same kind of email. Same technique and email from
| Google, the only difference was that it had some spam at the
| bottom of the email.
| jeroenhd wrote:
| I wouldn't call the banner huge, at least not in the examples
| I've found at [1]. The cookie banner doesn't look out of the
| ordinary and hides when you start scrolling.
|
| [1]:
| https://www.reddit.com/r/GoogleSites/comments/1ffz1a5/google...
| ; see websites like https://www.woofiepie.me/
| https://www.manuelfally.com/home https://www.wedding-
| whisperer.com/
| onehair wrote:
| I came here to say the opposite.
|
| Is this the screenshot you're mentioning?
| https://easydmarc.com/blog/wp-content/webp-express/webp-imag...
|
| If I received an email from google with text formatted like
| this. I would automatically have doubts it's anythig genuine.
|
| While Gmail isn't anything to boast about UI wise. Google often
| have good enough an consistent UI patterns where this
| screenshot looks like there was no thought put into it past
| slapping a google logo on top.
| charcircuit wrote:
| This trick of stuffing a huge mass of text into the title of
| something to make a Google email like this isn't a new trick and
| is a much bigger issue than this email not properly showing up as
| being forwarded.
| sandos wrote:
| Oooooh, finally!!!
|
| I received almost exactly this email a couple of months ago, but
| targeted at a google domains admin! I was, of course, also
| spooked by it. I did wait out and avoided clicking links in it,
| but I could not really find any references to this scam.
|
| What gave it away was that all email-addresses were masked, and
| those masks did not match up with any emails that I administer as
| a workspace admin. But yes, the email itself was legit, I googled
| that and the text passage matched. In my case it was an email for
| a deceased persons email, which ofc also did not match reality.
| But I was almost 100% at some point that someone had actually
| convinced Google I was deceased, and was going to access my
| entire Google account, talk about scary!
| rkerno wrote:
| This to me just appears to demonstrate what a house of cards
| email security really is....surely with the collective brains on
| this forum we can come up with an alternative that solves all of
| this. And surely Google needs to serve these sites under a
| different domain name....why aren't these sites published under
| something like 'hostedbygoogle.com'?
| monospacegames wrote:
| Announcing new Thiel-backed startup: Shadowfax
|
| Our secure, centralized and proprietary offering with native AI
| and blockchain layers will replace the obsolete cruft that is
| email. Already secured several DoD contracts and expect to
| fully replace email for all internal and external
| communications of the federal government by 2027.
| jerf wrote:
| All of the alternatives that can actually happen involve
| handing over full control of the system to one company, and
| thereby eliminating email's major remaining value, which is
| that it is a thing not controlled by one company.
|
| The technical problems are challenging but solvable. The human
| problems are not. Nobody with the resources to truly solve the
| problem is willing to do it to create an open platform where
| they don't get effectively all the money and control, but then,
| the rest of the world is not terribly willing to let them have
| all the money.
|
| Hence the impasse we are at.
|
| This is the problem you have to solve, not a technical one.
|
| (See also "why the metaverse where we do things like share
| avatars across all services is a stupid idea that will
| effectively never happen". It writes well in a novel, but in
| practice it requires World of Warcraft to accept that someone
| can run around in it as Mickey Mouse while wielding a Call-of-
| Duty-branded sniper rifle, and none of the relevant rights
| holders will ever agree to that, for all kinds of reasons. The
| technical problems are also formidable but they are nothing
| next to the fact nobody will ever agree to this.)
| arianvanp wrote:
| I've seen a similar attack in my inbox recently where people do
| the same trick by sending an email to
| yourgoogleaccount@google.com instead of Gmail.com and then
| forwarding the bounce from Google's mail servers to
| yourgoogleaccount@gmail.com with a spam message smuggled at the
| end.
|
| Passes all checks. Just kinda weird that a postmaster error is
| intertwined with a phishing campaign. But easy to gloss over as a
| non-technical user.
|
| In my case the phishing campaign told me I won some construction
| tools or something.
| slig wrote:
| I've been getting those for weeks, makes me think Google has
| given up email.
| h1fra wrote:
| hosting sites under google main domain is for sure a bad
| decision, I could have easily been caught by that since I wasn't
| even aware of this feature.
| detourdog wrote:
| I consistently get the same phishing emails. From the headers I
| assume they are coming from a google service. I have been
| reporting them using google's reporting page for over a year.
|
| https://support.google.com/mail/contact/abuse
|
| Only in the last couple of weeks have a seen a decrease in one
| particular source. I always thought they were using a gmail
| mailing list service.
| ddtaylor wrote:
| I actually have had the FBI seize all of my Google account
| materials before when I was convicted of computer hacking. The
| search took place in 2016 and 2018 as they came back and took
| everything a second time.
|
| Anyhow, they don't do it at all like this. I would have to check
| my discovery for some details and it's in cold storage, but they
| basically just send an e-mail to a specific department at Google
| and have that communication. They go through a decent amount of
| trouble to try to NOT tip you off.
| NitpickLawyer wrote:
| Interesting. Would that request somehow get logged / tagged at
| some point and make its way into "your" account full data in
| say a GDPR "give me all the data you have related to my
| account" type of a request?
| zOneLetter wrote:
| It's a Friday and your comment is the first thing that got me
| 10% awake. Please, do spill the tea. There must be a story
| there...
| edm0nd wrote:
| Let me guess, the raid warrant got signed for either CFAA
| violations, wire fraud, or a conspiracy charge.
|
| Hope you lawyered up and came out okay.
| ianhawes wrote:
| I'll fill in the details for the curious. You receive an email
| from `usernotice@google.com` with this body:
| Dear Google user, Google received and responded to
| legal process issued by the United States Department of Justice
| (<FEDERAL DISTRICT>) compelling the release of information
| related to your Google account. A court order previously
| prohibited Google from notifying you of the legal process. We
| are now permitted to disclose the receipt of the legal process
| to you. The agency reference number or case number on the legal
| process is <DISTRICT COURT CASE NUMBER>. For more
| information about how Google handles legal process, view our
| transparency report at http://www.google.com/transparencyreport
| /userdatarequests/legalprocess/. Google is not in a
| position to provide you with legal advice or discuss the
| substance of the legal process. If you have other questions
| regarding this matter, you may wish to contact an attorney.
| Please reply to this email and/or include the case
| identification number located in the subject line in any
| further communications regarding this matter.
| Regards, Legal Investigations Support Google LLC
|
| --
|
| In the case of a Federal Grand Jury subpoena, the Government
| will request a delayed notification of 1 or 2 years to prevent
| the service provider (i.e. Google) from notifying you. A
| subpoena only provides generalized records and not content. So
| things like billing information, login records, etc.. are fair
| game. The government is required to obtain a search warrant for
| actual data (i.e. your emails). Typically, Google will not
| notify you about executed search warrants against your account.
| upofadown wrote:
| People keep trying to use DMARC as some sort of sender
| authorization scheme. It continues to be a server reputation
| scheme.
|
| An unsigned email is still anonymous, no matter what DKIM and SPF
| say. It should be treated as such. No one should ever think: This
| email passed through a Google email server at one point. It must
| be legit.
| btown wrote:
| IMO the real vulnerability here is that you can put a URL in the
| App Name for a Google OAuth app, and Google will render that in
| no-reply emails to arbitrary addresses from its root domain. (And
| even if that render is not clickable, if you make the surrounding
| text scary enough, the victim will navigate there.)
|
| The fact that any number of keep-DKIM-intact forwarding services
| can be stacked on top is almost secondary - though educational.
|
| There should be no legitimate reason for the App Name of an OAuth
| app to contain a URL, and especially one containing google.com.
| _That_ is where this should be fixed.
| artee_49 wrote:
| TLDR:
|
| Google allows you set input long paragraphs and URLs into a field
| called "App name" and they then send you an email with the
| paragraph you entered in (malicious with phishing links) to your
| inbox. Since this is sent by Google, it's DKIM signed and passes
| DMARC so you can simply download the entire email and just send
| it as a raw email to other people and it'll continue to be signed
| and land in their inboxes.
|
| The other thing is that with these we cannot change the "To"
| header in the email (not envelope TO (which is where email is
| delivered to) but rather what shows up in the "To" when the
| client renders the email) and so the attacker bought a domain
| that looks like it's google owned "(rand)goog-ssl.com". When
| looking at emails in your inbox ensure that the "To" is always
| valid along with the "From".
| gunalx wrote:
| Ny main gripe with e-mail spam currently is hos difficult
| mainstream Clients make kt to actually review the headers.
| brongondwana wrote:
| I'm working on the solution to this (co-authors from Google and
| Yahoo, it's legit):
|
| https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motiva...
|
| Note that it doesn't help avoid Google actually sending out a
| message with user-provided text in it, but it does stop it being
| replayed to you without Google intending it, because the SMTP
| FROM/TO are protected.
|
| The motivation draft doesn't include technical detail, see early
| drafts of the technical detail in the various related docs at:
|
| https://datatracker.ietf.org/wg/dkim/documents/
| brongondwana wrote:
| Bah, the datatracker doesn't list the candidate documents.
| Here's some direct links:
|
| https://datatracker.ietf.org/doc/draft-chuang-dkim2-dns/
|
| https://datatracker.ietf.org/doc/draft-gondwana-dkim2-header...
|
| https://datatracker.ietf.org/doc/draft-gondwana-dkim2-modifi...
|
| https://datatracker.ietf.org/doc/draft-robinson-dkim2-bounce...
|
| https://datatracker.ietf.org/doc/draft-robinson-dkim2-messag...
| btown wrote:
| How would this work with mailing lists/groups? A common pattern
| is to have emails from third parties to e.g. accounts-
| payable@example.com be auto-forwarded to members of the
| relevant team.
|
| Would the end recipient team member's receiving system need to
| be set to "trust" the mailing list forwarder, or internally
| track what lists it is on to be able to understand that the
| original recipient accounts-payable is a valid recipient?
| brongondwana wrote:
| Glad you asked! In a similar way to ARC (but better). The
| mailing list/group would add its own signature, and
| potentially a Delta-Body or Delta-Headers describing what
| changes it made (so that the verifier could undo the changes
| and verify the original signature, plus determine which
| changes were made by which hop).
|
| So you'd have something like:
|
| DKIM2: i=1; mf=sender@trusted.com; rt=accounts-
| payable@example.com; d=trusted.com
|
| DKIM2: i=2; mf=bounce@example.com; rt=me@mydomain.com;
| d=example.com
|
| So I could tell that the message came through example.com,
| and verify their signature on the message, as well as verify
| that trusted.com had intended the message to go to
| example.com in the previous hop.
| latchkey wrote:
| This is amazing and I really appreciate you commenting
| here, but wow, my gut feeling is that this just feels like
| a yearly car registration sticker on top of the previous
| year and then a razor blade cut through it to prevent
| someone from stealing it.
|
| At what point do we rip it all off and restart?
| igtztorrero wrote:
| So DKIM,DMARRK,SPF and all that stuff and we still get spam
| dangerous mail ?
| 1718627440 wrote:
| Yeah, I recently started to administer a mail server. Most Spam
| comes from gmail lists (always newly created) with tons of
| headers explaining, why this absolutely isn't Spam, sometimes
| even longer then the content of the message itself.
| guluarte wrote:
| Is Google Sites used for legitimate purposes? I've only seen them
| used for spam and phishing.
| Fishkins wrote:
| At one point the org I work for used it for internal
| documentation. They migrated off of it many years ago, though.
| happyopossum wrote:
| Technical details aside
|
| >The branding and language were polished and professional >There
| were no obvious grammar issues or suspicious attachments.
|
| Really? No. Not even close to true. That looks nothing like
| professional, native-english-speaking legalese (which it would be
| if it were actually a notification from Google).
| happyopossum wrote:
| Post is several months old, and it appears that the underlying
| OAuth issue was fixed by Google a while back - you can't make
| arbitrarily long app names anymore...
| dajonker wrote:
| Would this be preventable by setting strict alignment for SPF?
| i.e. aspf=s in the DMARC DNS record.
| justusthane wrote:
| No, it wouldn't. SPF alignment just verifies that the Envelope
| From address matches the Header From address, and in this case
| both are no-reply@accounts.google.com, so SPF is aligned.
|
| Strict vs relaxed just specifies whether a subdomain address is
| aligned with a different subdomain (or root domain) address.
|
| Note that autoforwarding an email, as is happening in the
| article, is different from clicking Forward in your mail
| client. When emails are automatically forwarded, generally all
| the headers, including Envelope From, are preserved, so to the
| recipient it looks like it came from the original sender, not
| the party who forwarded it.
|
| See "Forwarding versus Remailing" here:
| https://en.wikipedia.org/wiki/Email_forwarding
___________________________________________________________________
(page generated 2025-07-25 23:01 UTC)