Live data from Hacker News

Lies we tell ourselves about email addresses

gitpush--force.com

181–190 of 197 posts

Re: Lies we tell ourselves about email addresses

#181

Earlier quoted context omitted.

What's the most common thing you hear when you do this? Usually its nothing, but the second most common thing is: "no, sir, your email address." It gives me the fuzzies every time to explain I own the domain, and every email address on it is mine. Since I have it on my phone, I can usually receive the email that they send very quickly and prove that everything's working fine. I am wondering how hard it is to do this…

The best one was when someone said they were going to give me excellent service because “you work for corporate”, confusing the company name before vs. after the @ sign. I forget which company it was now but the agent was convinced I must be someone important. I was torn between explaining and letting them believe it :-) Most of the time, folks just don’t understand why their company name is in the address and they t…

maybe i can write a whatthreewords style "email identity mapper" so you put in "walmart.com" and it spits out "busybee223@example.com" and "autozone rewards" yields "Horserider184@example.com"

then if you start getting spammed, you use the w3w style thing to reverse it and see what site/entity sold your email...

then all of the "this doesn't/won't work because they'll just spam the entire domain" arguments go away, the "no, your email address" style comments go away...

Re: Lies we tell ourselves about email addresses

#182

Earlier quoted context omitted.

How do you deal with sending emails? When I was self hosting my emails would be flagged by Gmail (or any other email providers) so I effectively only had a self hosted inbox, which sucks

Not OP, but I self host a few domains. I was worried about not being able to send emails, but is seems that as long as you setup properly SPF/DKIM/DMARC you're fine. You may have problems if using a domestic address though. For the configuration, the best bet is probably to use a product that makes it easy to configure the above three, there are a few alternatives around, like Stalwart [1] or docker-mailserver (which…

How did you manage to get Hotmail/Outlook to accept your email?

I got everything setup correctly, but Microsoft seems insistent on silently dropping my email.

Re: Lies we tell ourselves about email addresses

#183
post #179

Earlier quoted context omitted.

Realistically, people would need to go out of their way to have an e-mail with the domain part longer than a hundred ASCII characters (although considering Punycode, this limit perhaps should be more like 200, for CJK domains...) so if they do, well, it's their problem. I just don't like the idea of allowing to paste 20 MiB-long text into the input field for what normally is a "short line of text", so there should be…

Yes there should, and the maximum size of what fits into a 512-octet DNS/UDP query packet, less header and EDNS0 and whatnot, is going to be that limit, ultimately. Because SMTP-based Internet MTSes that do not look up MX resource record sets in the DNS, and do not begin at DNS/UDP, do not currently exist. (-: Even if they magically all switched to starting at DNS/TCP, that is still only 64KiB less header and EDNS0 a…

I've actually looked at RFC 1034 § 3 you've mentioned in another comment, and it states

    To simplify implementations, the total number of octets that represent a
    domain name (i.e., the sum of all label octets and label lengths) is
    limited to 255.
Which, AIUI, corresponds to maximum of 253 ASCII characters (including dots) in the common "subdomain.domain.tld" string format. So "\.{1,100}@\.{1,253}" it is (because, again, it's probably very likely that I wouldn't want to interact in the first place with people who think that the local part of their e-mail having more than a hundred characters is reasonable).

Re: Lies we tell ourselves about email addresses

#184
post #3

Add the lie "emails are delivered instantly, so the user can click a link I email them within 1 minute" And the lie "users always read emails on the same device they're logging into a website with" And the lie "users can always view HTML email so no need to send a plaintext equivalent, especially if I have a long complex URL I want them to click" And the lie "Clickable links sent in email are more secure than passwor…

I don't think it's about security. It's about fobing off password resets on somebody else.

This is market-dependent. We offer email OTP login for small business customers because it is “poor man’s SSO”. You’re basically validating the recipient is still at the company, able to receive at their work email.

Larger customers have IT staff and set up OIDC or SAML with us. We don’t add an SSO tax.

Re: Lies we tell ourselves about email addresses

#185

Earlier quoted context omitted.

The best one was when someone said they were going to give me excellent service because “you work for corporate”, confusing the company name before vs. after the @ sign. I forget which company it was now but the agent was convinced I must be someone important. I was torn between explaining and letting them believe it :-) Most of the time, folks just don’t understand why their company name is in the address and they t…

maybe i can write a whatthreewords style "email identity mapper" so you put in "walmart.com" and it spits out "busybee223@example.com" and "autozone rewards" yields "Horserider184@example.com" then if you start getting spammed, you use the w3w style thing to reverse it and see what site/entity sold your email... then all of the "this doesn't/won't work because they'll just spam the entire domain" arguments go away, t…

Good thought experiment! Makes it hard to remember the correct address for each site, but meh, that's the job of my password manager anyway.

Re: Lies we tell ourselves about email addresses

#186

> TL;DR: Don't overthink it, just send a verification email. pretty bad advice, if taken only as written, without adding more flavor on top. the major email providers will penalize you if you generate too many undeliverable emails. thus, if you just send a verification email without any pre-validation, it's pretty easy to get into a DoS situation where current/valid users don't get important email sent to them, or th…

[flagged]

Re: Lies we tell ourselves about email addresses

#187

> It’s likely that more people out there are being filtered by badly-implemented form validation than there are being filtered by their own need of hand-holding. I wish this was asserted with evidence. The author might suggest this because they have unrealistic views of some users. > In the year of our lord 2026, you can reasonably expect your users to know how to type their own email address - or even better, auto-i…

[flagged]

Re: Lies we tell ourselves about email addresses

#188

Earlier quoted context omitted.

maybe i can write a whatthreewords style "email identity mapper" so you put in "walmart.com" and it spits out "busybee223@example.com" and "autozone rewards" yields "Horserider184@example.com" then if you start getting spammed, you use the w3w style thing to reverse it and see what site/entity sold your email... then all of the "this doesn't/won't work because they'll just spam the entire domain" arguments go away, t…

Good thought experiment! Makes it hard to remember the correct address for each site, but meh, that's the job of my password manager anyway.

one wouldn't have to remember. if the address you gave out using the w3w-style encoder starts getting spammed, you can reverse it with the w3w-style decoder.

you'd need an app or a mnemonic device of some sort if you wanted to give an email out in public as opposed to sitting at a computer. but ideally on the computer when you notice spam you just reverse the email address back to who you gave it to; "target.com", "kroger.com"

Re: Lies we tell ourselves about email addresses

#189

This is cute and all. But for anyone coming here for real-world advice: just use a regex, normalize to lowercase, and surface any errors to users so they know if their email got rejected. This will avoid 99.9% of issues and work for 100% of real human users. This is what everyone else does, and if you have a user with an esoteric email, they will still be able to furnish another one that passes this validation.

Verify all email address entries before you start using it... I absolutely HATE how much garbage I get because a few people don't understand you actually have to get an email address before you start using whatever you like.

Right, maybe I worded my response a bit vaguely. Of course you need to do an opt-in and verify them.

My point was rather that if you are operating a service with human users, there is no need to deal with quoted local parts, mixed-case, non-ascii, etc. You will just run into bugs (oh, the user signed up on an iPhone and the email field was auto-capitalized and now they can't find their account?) for almost no marginal benefit.

Re: Lies we tell ourselves about email addresses

#190

"Regex is hard, regex wizardry is rare, and regex engine implementations are inconsistent. It’s very, very easy to accidentally get it wrong without realizing it." The what now? I'm struggling to take this seriously because a decade ago regex where common knowledge, like if you don't have a handle on this you should probably go get a job in marketing levels of common knowledge. Has the profession fallen off this far…

Sad truth: Yes. Yes, it has fallen off this far in the last ten years. If you look a little further back, say to 2006-ish it's far worse than that. Back then there were 'bright' middle-school ROV team members writing C and Ada+Spark for Arduino-board control-by-wire small craft to perform simulated ocean sample collection and tool manipulation tasks and winning in the unlimited class against university competition at…

What the actual fuck. It's not like we're talking about sed/awk fuckery or manual memory management. Regex syntax is a basic programming concept that is natively supported in most languages. Next you'll tell me these incompetents can't normalize database tables...
Post reply on HN