[HN Gopher] The Quirks of Gmail UI
___________________________________________________________________
The Quirks of Gmail UI
Author : todsacerdoti
Score : 187 points
Date : 2021-03-09 09:31 UTC (13 hours ago)
(HTM) web link (hanami.run)
(TXT) w3m dump (hanami.run)
| _ZeD_ wrote:
| from the article
|
| >>> Which one looks more trustworthy? Obviously A1 looks better.
| B1 has a suspicious text "via way.hanami.run".
|
| uhh... what is the problem with gmail showing the "via ..."
| badge? why, as an end user, should I feel less trust in the
| message?
| 0dmethz wrote:
| As a typical end user you probably won't understand what that
| "via" means. All you see is that your e-mail was sent "via"
| some unknown thing you don't recognize.
|
| Even if you do understand - isn't the "via" specifically
| designed to reduce trust? "Hey, head's up, this message
| actually came in through this third-party"
| moyix wrote:
| I recently had to just disable the Gmail spam filter using a
| custom rule [1] because the false positive rate was awful - 90%
| of the stuff in my spam folder was legitimate, including Google
| Calendar invites and normal GitHub communication.
|
| Unfortunately I'm starting to get the feeling that Gmail is no
| longer a high priority for Google, and so it's slowly bitrotting
| like so many other Google projects.
|
| [1] Matches: {(to:me) (deliveredto:myaddress@gmail.com)} Do this:
| Never send it to Spam
| rurp wrote:
| I didn't realize how many false positives Gmail had with spam
| for the longest time. An astonishing amount of legit messages
| get wrongly flagged for my account. Given that the UI hides the
| spam folder, I would bet that most people have no idea how many
| messages they miss from this.
| judge2020 wrote:
| Google Docs[0] and Calendar invites[1] themselves are often
| spam so i'm at least glad they don't outright whitelist
| domains. What is spam to some might not be spam to others.
|
| 0:
| https://support.google.com/drive/thread/75341417?hl=en&msgid...
| and
| https://support.google.com/drive/thread/5207602?hl=en&msgid=...
|
| 1:
| https://support.google.com/calendar/thread/12665854?hl=en&ms...
| (G response: https://support.google.com/calendar/thread/1342950
| 5?hl=en&ms...)
| mjthompson wrote:
| It'd be nice if Gmail could get with the times and add proper
| custom domain support to the consumer grade service. These email
| forwarding services aren't really ideal, and people shouldn't
| need to use them. They're never really going to have the tier of
| security as, say, Gmail.
|
| More generally, the problem of email address exhaustion on
| consumer services is getting worse. Imagine being a kid making
| your first email account on Gmail or Outlook.com that doesn't
| look totally unprofessional. I got lucky to get full name @
| gmail. (But, it's to Google's credit that they don't do the inane
| Yahoo approach of recycling addresses.)
| Ayesh wrote:
| Not defending gmail, but for them offering a gmail.com address
| is working out for many. Outside HN and tech, I doubt people
| care if their email suffix is `@gmail.com`.
|
| Google Apps (or whatever they call it these days) is very
| affordable and gets many aspects of emails right. There are
| other well established alternatives too, like protonmail
| signal11 wrote:
| > if Gmail could get with the times and add proper custom
| domain support to the consumer grade service
|
| Yes please. Especially since Microsoft offers it to a limited
| extent on Outlook.com for Microsoft 365 Home subscribers
| ('limited' in the sense, the domain _must_ be registered with
| GoDaddy).
|
| In case any Google employees are reading this: this would be a
| very useful feature for one.google.com.
|
| > More generally, the problem of email address exhaustion on
| consumer services is getting worse.
|
| And there's another pernicious problem: if you have a
| firstname@gmail.com or first.lastname@gmail.com, you're likely
| getting a ton of misdirected email even if your name isn't that
| common.
| kureikain wrote:
| Hi, I'm the OP of this article. I'm not intending to click bait
| this article and my mistake for not compeltely explanation DKIM.
|
| My point is that as an average user, when seeing this, what is
| their expectation. This is what happen when a user asked me about
| that today.
|
| I understand DKIM. However, when one send a plain email without
| any DKIM, why google say nothing on their UI. If they say: "This
| email has no DKIM", it would be better. Now, the one who signed
| that email(original email didn't) get this "Via way.hanami.run"
| and an normal user will confuse when seeing it.
|
| BTW, We do support DKIM signing in our dashboard, it will ask
| user to setup MX, SPF, and DKIM. However, many mail services will
| let DKIM an optional thing. Even google/zoho.
|
| You can add domain and send email just fine without configuring
| DKIM for your domain. Google will sign your message with
| gappssmtp.com domain and won't say anything about "Via"
| itsadok wrote:
| This is kind of like how http sites look totally fine in most
| browsers, but an https site with a self-signed certificate will
| cause a "DANGER! ENTER AT YOUR OWN PERIL" screen to be shown.
| shimonabi wrote:
| The most annoying thing about the current Gmail UI is that I have
| to have the tab open for another minute after deleting or
| achiving mail, otherwise it gets restored automatically because
| of the Undo countdown feature. Insane!
| rubyist5eva wrote:
| The most infuriating thing about gmail is how icons with
| destructive actions appear under my mouse cursor when I move my
| mouse over it and I'm just trying to click on the email to drill
| down into the conversation from the inbox. Every, f*cking time
| i'll just lazy throw my cursor over and just happen to end up in
| the zone where Archive or Send To Trash is and click it without a
| chance to react. I despise gmail with a burning passion. Google
| UX design is a complete joke overall.
| michaelhoffman wrote:
| I have a similar keyboard problem. With relative frequency the
| focus is stolen from a text input box to the top level. Usually
| this is just an annoyance, but sometimes it happens right as
| I'm typing an "m" (which results in me accidentally muting a
| conversation) or an "e" (which results in me accidentally
| archiving a conversation).
| rubyist5eva wrote:
| absolutely bonkers - reminds me of Jira where you can
| accidentally just hit 1 key and seemingly a bunch of random
| garbage happens.
|
| WE HAVE MODIFIER KEYS FOR A REASON
|
| It drives me up the wall how absolutely godawful contemporary
| software is.
| jeffbee wrote:
| This is why keyboard shortcuts in Gmail are disabled by
| default. You have to turn them on, if you want to live
| dangerously.
| remram wrote:
| I've noticed this too. It feels a lot like hitting the
| touchpad by mistake, except I don't use a touchpad. The focus
| is just lost mid-typing and a bunch of shortcuts get
| triggered.
| Isthatablackgsd wrote:
| And don't forget the image attachment that Google ~~insists~~
| forcibly put the image inline the message instead of as
| attachment. Why would they make it complicated and made a weird
| drag-n-drop rules for image only. It would be nice if Gmail
| team simply add the option to disable adding the image inline
| the message. Since it is Google, more likely Gmail will sunset
| their service before adding that option.
| marshmallow_12 wrote:
| Is it just me, or are those social media icons at the bottom of
| his page gigantic?
| opheliate wrote:
| They're rendering at a fairly reasonable size for me, 30x30px.
| prionassembly wrote:
| A fairer title should be "A quirk of Gmail UI".
|
| The overall UX of Gmail as of 2021 is a mixed bag, and this is
| somewhat generously speaking. I mostly rely on search to find
| emails, as tags get hidden, the "Important" mailbox overwhelms
| messages the AI didn't deem "important" and the spam filter has
| never been worse. I was expecting a review of... the quirks of
| the Gmail UI.
| uptown wrote:
| My favorite Gmail quirk is how your account gets locked out for a
| few hours if you bulk delete thousands of emails, and how trying
| to archive every message from a very large inbox fails silently.
| davidmurdoch wrote:
| Mine is when they lock you out because you don't, and never
| did, own the phone number now listed on the account:
|
| https://news.ycombinator.com/item?id=26369992
| srean wrote:
| Folks discussing this are knowledgeable about the SMTP protocol.
| So let me ask something I have always wondered about -- what was
| the idea behind HELO, what purpose does it serve in the protocol.
|
| Thanks to all who take out their time to answer this 'ought to be
| obvious' question.
| megous wrote:
| > the command may be interpreted as saying "Hello, i am
| <host>".
| srean wrote:
| Indeed but what's the purpose of that. The SMTP server knows
| the IP address anyway and can DNS lookup if needed. The one
| chatting with server can say hello followed by any arbitrary
| string
| ink_13 wrote:
| > can DNS lookup if needed
|
| Can it? Not every machine that sends mail is on the public
| Internet.
| quesera wrote:
| SMTP (1982) predates DNS (1985).
|
| Reverse DNS was added to SMTP servers as an anti-spam
| feature about 15 years after HELO was established.
|
| But to be honest, I'm not sure HELO was ever really
| _useful_. In the very early years, it might have been
| appropriate to reject messages where the MAIL-FROM domain
| did not match the HELO domain. Not for long though.
| albertgoeswoof wrote:
| This is the crazy thing about email, it's ancient, 39
| years old. I bet it'll still be around in 20 years from
| today.
| jeffbee wrote:
| SMTP is an interesting protocol because the server opens the
| session with the banner, unlike HTTP where the client speaks
| first. I think a better question is why does the banner exist,
| and what purpose does _it_ serve?
|
| HELO/EHLO gives us a way to negotiate ESMTP, which is what
| practically everyone uses today.
| petercooper wrote:
| Running an email forwarding service has to be a pretty thankless
| task, so hats off to the author if they're doing it right, even
| if the UI isn't quite on their side.
|
| I send a lot of (wanted) mail and some subscribers have various
| forwarders set up which result in the eventual recipient server
| rejecting the mail due to the forwarded mail failing SPF and
| DMARC. It's a nightmare as we get the bounce backs telling us off
| but it's because the forwarders aren't, of course, sending from
| IPs included in our SPF record. (There are clearly ways to do it
| properly, but a lot of mail forwarding systems appear not to?)
| supermatt wrote:
| This is one of those examples of it not being done properly.
| kureikain wrote:
| Thanks you Petercooper. Are you the one that run Ruby Weekly?
| If so, thanks for your work all these year.
| [deleted]
| Ayesh wrote:
| Gmail is not wrong.
|
| The "via" text is only shown if the email is DKIM-signed by a
| different domain name than that envelop From domain.
|
| If the email is signed by the same domain as the From domain,
| there will be no "via" text.
| LukeShu wrote:
| It also shows the "via" if the SRS domain is different than the
| letter From domain.
| stedaniels wrote:
| Came here to say this. It makes perfect sense to me. Maybe
| we're missing something?!
| Ayesh wrote:
| I think it's because the author thinks "via" text is a
| negative thing?
|
| They run an email forwarding service, so their SPF records
| will fail, but an untampered email should still pass DKIM. in
| fact, that's how most email forwarding setups work. If the
| message is tampared, and re-signed with the forwarding
| service's DKIM key, it's correct for Gmail/email-client to
| show the via-text.
| albertgoeswoof wrote:
| I've created two email startups (https://ohmysmtp.com and
| https://idbloc.co) - email is hard, thanks in no small part to
| these issues which are basically undocumented or at least not
| specified.
|
| To avoid this, the Hanami team could add a reply-to header that
| routes back to the original sender, update the from header to
| come from them (to pass DKIM and SPF), and instead of forwarding
| on directly, re-build the email and resend it as a fresh, DKIM
| signed-one. This is how we do it at IdBloc (we add the via bit):
| from: Original Sender via IdBloc.co <sender-at-
| domain.com@users.idbloc.co> reply-to: "Original Sender"
| <sender@domain.com>
|
| If they want to act as a complete firewall in between, they can
| change the reply-to address as well and completely rebuild the
| email each time.
| kureikain wrote:
| Thank you. I'm thinking about it as well but many other email
| forwarding service forward it as it's. so when I do different,
| they kind of confused. Plus, many mail client show the from as
| well. So it confused user quite a bit.
| albertgoeswoof wrote:
| Agree, it's not really email "forwarding" if you parse the
| email then resend it.
|
| Then again what is email forwarding anyway, it's all such a
| mishmash
| supermatt wrote:
| These "issues" are EXTREMELY well documented AND specified.
|
| To be fair, we don't actually know the authors intent (and I
| would argue that they dont either).
|
| They should be either forwarding the signature (in the case of
| relaying) or signing with the senders domain key. They are
| instead signing with the relay domain key, which is all but
| useless.
| SavantIdiot wrote:
| @supermatt you really get this stuff. Is there an OReilly (or
| other) book you'd recommend, or is all this knowledge part of
| the vast, distributed online corpus of IETF RFCs and
| StackOverflow questions?
| KronisLV wrote:
| Agreed, any links (or references to books) about the
| subject matter would be helpful!
|
| At this point i feel like a lot of e-mail related topics
| are full of "unknown unknowns" to me and many other
| developers. It's hard to say whether we're missing bits of
| information that are considered common knowledge or maybe
| e-mail related development doesn't have enough
| discoverability (like blog posts, tutorials and so on) to
| make it easier, like configuring HTTPS in Apache2/httpd
| would have.
|
| Or maybe the whole domain is just full of inherent
| complexity due to its history (SPF, DKIM, DMARC etc.).
| albertgoeswoof wrote:
| Re. docs - not really, the "via" prefix is not documented in
| any RFC, it's Google who are ad-hoc defining this and making
| up a new standard.
| [deleted]
| RIMR wrote:
| They haven't made up a new standard. The standard already
| exists. The "via" is just a way of visualizing this
| standard.
|
| Just because the "via" UI element doesn't appear in any RFC
| doesn't mean it doesn't represent something that does
| appear in an RFC.
| albertgoeswoof wrote:
| It needs to say something like Reply To MUST match From,
| if not the email client MUST display a visual
| representation
|
| I don't see that kind of thing in an RFC anywhere though?
| Ayesh wrote:
| I think the "problem" shown in this article is when Gmail
| shows the "via" text when the From domain is different to
| the signature header.
|
| It's very common to have From addresses different to
| Reply To; a contact form for example should do this.
| opheliate wrote:
| Noob question from someone with little knowledge of email:
| Doesn't Gmail just move emails which fail DMARC to spam outright?
| Even though A1 in the op does look more trustworthy, I would have
| thought Gmail would just disregard it, since a DMARC fail is a
| big red flag? In that case, I would think B1 looks a _lot_ more
| trustworthy, since it 's not marked as spam. Or is the picture a
| bit more complex than that?
| albertgoeswoof wrote:
| No, Dmarc is not a red flag if it's not setup, most email
| providers don't require dmarc to be setup. Many, many emails
| are sent that do not pass dmarc.
|
| The reason is that if you maintain dmarc records you have to
| handle spam complaints and bounce reports. So if you're using a
| provider like mailgun or ohmysmtp, you still have to set up a
| receiving smtp server even if you're only sending outbound
| mail.
| stedaniels wrote:
| It does _fail_ DMARC.. but the DMARC record for getopty.com
| tells it to do nothing if it fails.
|
| It's policy is set to "none". You normally do this when you are
| starting to investigate your DMARC setup and want the stats.
| This way you can fix things before you up the policy through
| quarantine and then to reject.
| upofadown wrote:
| I can't help pointing out that the root cause here is that the
| email server is signing various things in the email that the
| email server did not originate. There would be no problems with
| forwarding if the originating _user_ signed the email instead.
| The identity of the email originator is what the email recipient
| is actually interested in. The UI could then show if you actually
| know the entity sending the email rather than if your email
| server knows the originating email server.
| [deleted]
| supermatt wrote:
| They both look like spam.
|
| B1 is displaying a verified relay that doesnt match the sender
| domain.
|
| The problem seems to be that the author doesnt want to display
| "via way.hanami.com", in which case he should set up DKIM for the
| domain he actually wants (the redacted domain) instead of
| "way.hanami.com".
|
| Really shouldn't be advertising yourself as a "mail forwarding
| service" if you dont understand that...
| ROARosen wrote:
| > while the message that failed both SPF and DKIM looks
| _correct_ on their UI.
|
| While the behavior can be annoying, the first picture in the
| article conveniently cuts of the profile image near the sender
| details. I believe when both fail gmail adds a question mark
| icon of a red unlock. So no, it doesn't look more correct.
| kureikain wrote:
| Hi, I'm the OP.
|
| I understand DKIM and i have written this part in the article
|
| > Somehow when we signed a message with DKIM, google decided to
| show the "Via way.hanami.run", which is technically correct
| because the message lack of DKIM signature for original email(I
| made a typo and type gmail in original article) address
|
| As in, I agree with gmail decision. My point is that, why when
| a message has nothing, gmail didn't say "warning: no DKIM
| signing".
|
| I just hope gmail makes that fact clear on their UI when a
| message has no DKIM signing.
|
| And sometime, to reduce minimal work for users, DKIM is
| optional for them. If they add our public key to
| `hanami._domain` we will sign it. But it's really tricky to
| configure DKIM for a normal user. Even gmail makes it
| optionally. In that case, gmail signed it with gappssmtp.com
| and yet, they don't say "Via gappssmtp.com"...
| jedberg wrote:
| > My point is that, why when a message has nothing, gmail
| didn't say "warning: no DKIM signing".
|
| Because 99.9% of users would say "What is a DKIM?"
|
| Google has decided that regular uses don't need to know if
| DKIM and SPF passed or not, because they don't know what that
| is anyway. They use those things in their spam filtering. If
| a message got past their filters, regular users assume they
| are safe, and even if it had DKIM status on it, that wouldn't
| change.
|
| Power users can bring up the second screen you showed if they
| want to be sure.
| lstamour wrote:
| If Chrome operated that way, we would still have broken
| locks on mixed-content SSL pages and no warning at all on
| non-SSL pages. The fact is, an attempt at security is
| better than no attempt at all, and visibly marking the
| insecure option as less secure is better than pretending
| security doesn't exist unless it's implemented 100% as
| expected (lock icon appears, etc.)
| jedberg wrote:
| I agree with you in theory, but in practice they are very
| different situations. For websites, the website owner
| loses traffic if they don't offer a secure experience --
| they are in complete control of their destiny.
|
| For email, the user loses deliverability and may not even
| be aware of it. Also it's often not within their control
| to fix. Marking non-signed emails as such would put a
| huge burden on email users and they might not even be
| aware of it.
| SavantIdiot wrote:
| > Really shouldn't be advertising yourself as a "mail
| forwarding service" if you dont understand that...
|
| Ouch! But isn't setting up the DKIM the way you suggest the
| responsibility of the domain owner and not Hanami?
|
| EDIT: Nevermind, I just read your replies below. Damn,
| forwarding is tricky business. OP should hire you.
|
| EDIT2: typo
| upofadown wrote:
| If you add your own DKIM then you have to mangle the from
| address to make it appear that the email is from your email
| domain. Which usually means some sort of "via" usage. So that
| would not fix the problem.
|
| This is a generic problem with DKIM, it breaks email
| forwarding.
| emersion wrote:
| No, DKIM doesn't break forwarding. If you just forward the
| message, the original DKIM signature remains correct.
|
| The original DKIM signature breaks if you edit the message
| body or its existing header fields.
| supermatt wrote:
| DKIM doesnt break anything because it applies to the original
| message. You simply forward the signature header (well, you
| forward everything - thats what makes it forwarding!).
|
| As I mentioned elsewhere, its not clear what the authors
| intent is - is it an originating server, or is it a relay. In
| both cases he shouldnt be signing with the relays key, but
| should either be signing with the domains key (if available)
| or forwarding the existing signature. Signing with the relays
| key is all but useless.
| upofadown wrote:
| >DKIM doesnt break anything because it applies to the
| message body.
|
| DKIM applies to what you set it to apply to in the DKIM
| entry. Here is what Gmail signs from the header (the body
| is signed by default) for their DKIM (taken from a recent
| Gmail originated message): h=Content-
| Type:List-Subscribe:List-Help:List-Post:List-Archive:
| List-Unsubscribe:List-Id:Subject:To:Message-
| ID:Date:From:MIME-Version:Sender: Reply-
| To:Cc:Content-Transfer-Encoding:Content-ID:Content-
| Description: Resent-Date:Resent-From:Resent-
| Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-
| Reply-To:References:List-Owner;
|
| Note the "From" in there along with a whole whack of other
| fields.
| supermatt wrote:
| Why would you change the from address? The whole point
| here is to forward, not re-mail. Everything should be
| forwarded.
|
| I kinda agree with what you said, but the point is that
| you shouldnt be mangling the from address when
| forwarding. That will definitely break DKIM, as its
| actually a required header fields in the sig - but theres
| NO reason to do that.
|
| p.s. Ive clarified that i meant "original message" not
| "message body" in my post.
|
| p.p.s Actually, I do think we are in agreement. I
| mentioned elsewhere that we dont know what the intent was
| - relay or origin, but in no case should they sign with
| the relays domain key.
| upofadown wrote:
| Kind of off the original point but that is where DMARC
| and SPF come in. This stuff has become a complex
| unworkable mess.
| megous wrote:
| That's a From inside the message. MAIL FROM in the SMTP
| protocol (envelope from, which you change during
| forwarding) can be anything else, and DKIM will still
| validate the message.
| jacobr1 wrote:
| It is the opposite. Forwarding (can sometimes) break DKIM. If
| you are reliant on DKIM (such as blocking messages with
| DMARC) then you need to account for the impact of forwarding.
| This has been a big problem with mailing lists, since they
| get caught in the middle. Mail might get blocked because of
| the signature failed and the mailing list gets blamed.
| japanuspus wrote:
| For anyone looking for a forwarder that has done their
| homework, I can recommend forwardememail.net [0]. The developer
| has commented on the issues here on HN a few times.
|
| [0]: https://forwardemail.net/
| kureikain wrote:
| Yes, they are great.
|
| But JFI, the email that has invalid SPF and DKIM in the
| screenshot is the one forwarded by forwardemail.
| btown wrote:
| Yeah - OP's docs don't even mention adding a DKIM key to your
| domain: https://hanami.run/docs/cloudflare_email_forwarding
|
| Compare to Google's instructions for the-artist-formerly-known-
| as-G-suite: https://support.google.com/a/answer/173535
|
| Gmail's UI has a lot of quirks (can we talk about how it's a
| productivity app with a fantastic search, that doesn't let you
| save searches?) but it's correctly calling out people who don't
| do DKIM correctly. OP's article doesn't even talk about
| anything other than DKIM; intended or not, the title is pure
| clickbait.
| laurent123456 wrote:
| You can actually create filters in Gmail which would be like
| a saved search. Once you've searched for something, click on
| the arrow on the right, and then "Create filter".
| btown wrote:
| Of course, and you can create labels that track that
| filter's application in the same way a materialized view
| would work. But we don't CREATE MATERIALIZED VIEW, or worse
| yet UPDATE a many-to-many table, every time we want to run
| an exploratory analysis on our SQL databases and save our
| ability to rerun that analysis for later, right? Because
| that would create a ton of bloat, and we might lose track
| of the labels that we actually want to be permanently
| meaningful, and if a label is ever added manually, there's
| no guarantee that the label tracks the initial intent of
| the search query.
|
| And that doesn't even get into the fact that any such
| labeling is visible as a tag on every matched conversation,
| leading to a need to have a concise name for your analysis
| to avoid information overload. Naming things is hard, and
| when designing interfaces, reducing cognitive load isn't
| just a nice-to-have.
| alisonkisk wrote:
| Gmail used to have saved searches
|
| https://irvineco.wixsite.com/goinggoogle/single-
| post/2014/10...
| agentdrtran wrote:
| Which you can only re-use by saving the filter as a label,
| and you can only have about 200 labels before performance
| starts to torpedo.
| gpspake wrote:
| My biggest gripe is that you can't sort by sender. Sure, you
| can filter but sorting by sender and visually pattern
| matching is the easiest way to cull and unsub from repetitive
| promotional emails that might otherwise not stick out in a
| cluttered inbox. It's absolutely insane to me that in 2021
| gmail doesn't have this feature that every other email client
| has had forever.
| tlogan wrote:
| Yes - the first email should clearly say that DKIM/SPF is not
| correct. In other words, if I mistakenly un-spam an email which
| has incorrect DKIM/SPF, then the gmail interface should still say
| that headers are not ok.
___________________________________________________________________
(page generated 2021-03-09 23:01 UTC)