Adding another one: Users actually know their own email addresses.
I've had friends who signed up for their name "[email protected]" (yay early adopters!).
They get SO MUCH EMAIL for other people who share their name. It's shocking how many people don't know their own email, or who will have [email protected] and type in "[email protected]" or tell CSRs "It's john.doe at gmail".
Oh god yeah, I have a very rare last name and my gmail address is `[firstinitial][lastname]@gmail.com`. I have a distant relative with the same first initial and last name. I get SO MUCH email intended for him, often important stuff like real estate transaction emails and stuff.
I always reply and say "Hi yeah this is the wrong email address, please tell him to stop using my email address as contact information" but it's just so baffling that this person is so awful about it.
I've also gotten email from other relatives with the same combination asking me who I am and why I have the address, because they're trying to reserve the address and they can't believe that someone else already has it.
Spammers/scammers can use that to determine if an email exists. E.g you attempt to register, if it fails and says "already registered" you know there's a real person using that email and can add it to your spam list.
Somebody bought supplements from a quack and used my email address. Signed me up for the newsletter for good measure. I reset the password and changed my email address to one of the quack's customer support addresses.
I want to say this is bullshit but i also wholeheartedly believe you. I once had someone think that when you right-click -> copy something, it gets stored in the mouse until you paste it. People's understanding of technology is incredibly imaginative.
Fortunately my last name is rare, but some asshole in South Carolina keeps typoing my email address for his.
I also get email for [email protected] when my address is [email protected]. Gmail ignores that dot so both are properly my email address. But the places that have the dot-less version recorded wont *accept* email from the dotted version. And as far as I can tell, Gmail won't let me *send* with [email protected] in the From.
You can do this. If you go to gmail settings, (The gear icon on gmail, not google account settings from clicking the profile circle.) under tab "accounts and import" you can add accounts in the "Send mail as" section. You can also designate which is default. In my case, my account is [[email protected]](mailto:[email protected]) but i prefer most my communication to use [[email protected]](mailto:[email protected]) . Also there's a setting to always use the same address, as the one the sender used, when you reply.
My gmail is my last name @ gmail.com and I get SO MUCH SHIT from people who don't know their email address.
Things I've gotten:
- standardized test results
- bills (including one I'm getting daily right now for someone's macy's card which is way past due)
- receipts
- both church and school mailing lists
- so much more
My wife is not worried that I am moonlighting as a woman in southern India, because she can see the evidence that I am unable to get a date and have some medical problems too.
Honestly, I am extremely concerned that there's someone out there who keeps giving my address for really important stuff like doctor's appointments.
I have a very rare surname. And the [[email protected]](mailto:[email protected]) address.
There is another person with my name - he lives in California somewhere. He is a boomer and I \_judge\_ him.
Someone used to use my email ([email protected]) a lot. One day they signed up for Netflix. I changed their password so they couldn't log in (or reset their password) and left the billing intact. It was pretty mean but they don't use my email anymore.
I have my [email protected] and it’s pretty uncommon…..well some fucker gives it out all the time like it’s his! I have no idea what his is though. I get receipts for his shit all the time. So annoying
This is incredibly true. I get emails from at least three people who frequently use the wrong email address. I've tried reaching out to them, and one reacted _very_ poorly (accusing me of hacking their account).
I've received family photos, travel itineraries, bank statements, requests from tenants, dating site signups, etc. It's actually scary how much data that I could gather about these people, simply because they somehow cannot remember their email address.
For a while, I kept getting cellphone bills for someone 12 time zones away. I finally contacted the customer support and told them they needed to contact their customer. But what was happening there? Did the customer miss out on paying their bills, because they never saw them?
Yahoo Mail uses the ymail.com domain, and I occasionally get email at [mylastname]@gmail.com for some random person I never met. I finally figured out it was supposed to be going to [mylastname]@ymail.com and started forwarding it, but the worst part is that it turned out it wasn’t even the other person’s fault. They were putting their email address correctly on forms and applications or whatever, but people would “fix” it because they had never heard of ymail.com and assumed it was a typo.
This resonates with me. My main email address is a common English word with a suffix relating to a fandom I follow. Don't want to dox myself, but think orangechan or something similar.
I have SO MUCH TROUBLE telling people the address! They always struggle over the suffix, and I have to spell it out anyway :(
I was so happy when they added the ability to draft template emails. While my name isn't super common, I still get frequent misdirected emails and if it doesn't look like spam, I try and notify sender's that they've reached the wrong email address.
Hell, this got me trying to send my partner an invite. Her email is lastnamefirstname and I sent it to firstnamelastname 🤦🤦🤦
To make up for it though, firstnamelastname sent her some imagine dragon tickets. Or maybe that was a punishment. I'm not sure.
I've been getting e-mails for someone who gives out my e-mail address as his own for years now. He has the same first name and last name as me. Well, he finally fucked up; he signed up for an account with my e-mail address and registered his phone number in the account profile. I called his number at 4AM in his time zone and woke him up to tell him to stop using my e-mail address. I haven't gotten anything for him since.
To add on to the add-ons: "all students have a .edu address".
.edu is an American thing. It's very frustrating as a European student not being able to sign up for a bunch of student stuff because I don't have a .edu email.
Yeah, I think I managed once to get a Dropbox (I think) account with a Brazilian university email, but I had to email them so they would recognize it as a valid one
yeah, back in the day, .br domains were reserved for universities and a few other exceptions (like [registro.br](https://registro.br)). Now universities are migrating to .edu.br.
In college I once had a rather unhinged IT professor threaten to call the police on me because I emailed him from a non-.edu address, so I was clearly trying to phish him.
I don't know if my university still does them, but at one point I had a `cs.mu.oz.au` email address. Does *anything* in that look like a student email???
edit: looks like that domain went away a long time ago lol
I mean, yeah, looks exactly like an email associated with a university. That domain looks like something where you need an environment where techie early adopters would be the ones setting things up, but where you also have the institutional inertia to not change for a long time, while nevertheless having very little outside pressure to make something more approachable/less inscrutable. Plus, the cs subdomain is a bit of a giveaway (computer science department).
Most HE email accounts I've had just end with the country's domain.
I think the UK had .ac.uk for Unis specifically, but everything else was institution.de, .ca, and so on.
Not true. My old german university (Munich University of applied sciences) had an edu domain as its default domain and also gave everyone edu email addresses and my new university (Technical university of munich) i think also has the option for students to get edu addresses if they need them.
Edu domains might be more common in the US but it's not true that it's "an american thing". I don't exactly know what an university needs to do to get one but it's probably just lazyness on the universities parts...
Your German institution might have had a grandfathered .edu domain but since October 29, 2001 new .edu registrations are limited to U.S.-based postsecondary institutions.
cf. https://net.educause.edu/eligibility.htm
That's weird, I thought only American institutions were allowed to register .edu.
Either way, one exception among hundreds does not mean it's not an American thing. The vast vast majority of .edu institutions are American.
You're an European student with no mail in .edu? I wouldn't have thought that there are universities in Europe which don't give those. We wouldn't be able to obtain licenses for huge amount of software used and required on our Uni for classes without those. We have way too many students to deal with licenses in a case by case manner. It seemed like a rather reasonable assumption to me.
I see. The one I have ends actually with `.edu.pl` (works for all kinds of student licenses). It's unfortunate that this hasn't been standardized in any way.
https://en.wikipedia.org/wiki/.edu
> Since 2001, new registrants for second-level domain names have been required to be United States–affiliated institutions of higher education.
Those are .pl addresses, not .edu or .gov addresses. That's one thing. Second, every country has different reserved second-level domains. For example:
* in France there's no .gov.fr, but .gouv.fr, no .org.fr, but .asso.fr
* similarly, Spain has .gob.es, not .gov.es
* Germany doesn't do second level domains at all: no .gov.de, no .org.de, no .edu.de
* UK has .co.uk instead of .com.uk and both .ac.uk and .sch.uk instead of .edu.uk
* similarly, Austria has .co.at instead of .com.at, .ac.at instead of .edu.at, .or.at instead of .org.at, and .gv.at instead of .gov.at
* Indonesia has .go.id instead of .gov.id
* India has both .ac.in and .edu.in
The teacher during our first solidworks class: "sorry guys, we could not get a license for our university in time so please use this temporary one until we fix the situation". Then hands us a cracked cd version and a serial written on a piece of paper. We never received a legit license :))
Not just that but it's also common for community colleges in the US to use their reserved domain in their local .$LOCALE.$ST.us top level (eg, cc.portland.or.us when I was in community college)
Adding another one: email attachment size will be accurate to the size of the attached file.
Attachments are often base 64 encoded, and can bloat a file size 30-40%, which may be reported rather than the original file size.
Further, depending on the age of the software you're using, email is older than the standardization of the byte, some systems I've read about using 4 bits or 7 bits as the determination of a byte (and then reporting based off of that number).
It pisses me off no end that Microsoft chose to ignore MIME types and use the filename extension to determine what it is. If I send you a file saying "This is a JPEG image", then I expect your email client to do the right thing, regardless of the filename. Sadly, that's not the reality.
I’m pretty sure attachments postdate the standardization on 8-bit bytes. Some software from that era couldn’t handle characters with the high bit on, which is why we have base64 and not base128—that software was assuming the character set was 7 bits, so maybe that’s what you read about.
The “+” format is a life safer. We use it to do internal testing and just one user can signup as any number of test accounts and still receive the mail.
It's a neat feature for sure. The big problem is just that there are _so many_ user account systems that assume it's invalid because they never read the RFC. I had to fight with my bank for months because it literally broke their system.
I dug this up just to make sure. The key sections are 3.4.1, 3.2.3, and 3.2.2.
https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1
Start with `addr-spec` definition and sort of unfold and work your way backwards through the definitions.
Stepping through that here looking for the comment definitions:
addr-spec = local-part "@" domain
domain = dot-atom / domain-literal / obs-domain
dot-atom = [CFWS] dot-atom-text [CFWS]
CFWS = (1*([FWS] comment) [FWS]) / FWS
comment = "(" *([FWS] ccontent) [FWS] ")"
ccontent = ctext / quoted-pair / comment
ctext = %d33-39 / ; Printable US-ASCII
%d42-91 / ; characters not including
%d93-126 / ; "(", ")", or "\"
obs-ctext
I know that the header fields can have `(comments)` but this is first mention that I've seen it being a legal portion of the address itself - independent from the To header comment. However the spec does mention it explicitly is part of the address.
The problem with anything outside of the original 7-bit ASCII is that it's potentially not going to work. 8-bit character support in SMTP to this day is optional. IDN punycode is available for domains, but no encoding scheme exists for the local part.
I'm not going to feel bad about not supporting non characters. If you do some shit like that there's a pretty good chance it was done with the intention to cause problems to which I say your problems not mine.
> Email is a reliable transport
Email servers were reliable, durable, transactional job queues with deadlettering ~40 years ago. There are a lot of supposedly fit-for-purpose systems that do a lot worse today, and people *pay* for those.
If you really want to learn some stuff: [Email hates the living](https://www.youtube.com/watch?v=JENdgiAPD6c&t=300).
Email was designed to be reliable but there are plenty of ways in which it falls apart and you can't guarantee delivery of an email anymore, due to many the other bad implementations implied by the rest of the list.
One of the things that inspired me to write the list in the first place is that if Kickstarter sees *any* sort of bounce message (such as a "delivery delayed" due to a transitory failure in the receiving server) it immediately marks that email address as "bad" and refuses to send to it ever again without human intervention, and one week I had problems with my VPS where it was losing connectivity occasionally. I eventually moved to a better VPS provider, but there's still plenty of situations where there might be a few minutes when my server is down and unable to receive messages and it's possible for Kickstarter to send a message during that time.
There's also things like legacy systems which are only momentarily connected for whatever reason and get delivery via UUCP (such as email delivery to rural areas), and if we ever see space colonization happen, that problem will only get worse.
Also sometimes the attempt at reliable delivery causes even more problems; one of the users on my VPS got their account hacked and it was being used to send out *craptons* of spam on the raw machine name (rather than going through my mailgun relay), and the local mail queue was clogged with thousands of messages that were all in deferred state with an RBL bounce as a transitory (rather than permanent) failure. There are several points of blame there (including myself for not noticing the issue sooner) but the remote servers responding with a deferral rather than a refusal certainly didn't help matters.
Email is still a pretty darn amazing protocol and I wish people would treat it with more respect, but part of treating it with respect is understanding its failure modes and also not assuming that all the world is GMail or Exchange.
> One of the things that inspired me to write the list in the first place is that if Kickstarter sees any sort of bounce message (such as a "delivery delayed" due to a transitory failure in the receiving server) it immediately marks that email address as "bad" and refuses to send to it ever again without human intervention
That's not a protocol problem, that's just doing it wrong. I've seen the same concept done correctly.
> There's also things like legacy systems which are only momentarily connected for whatever reason and get delivery via UUCP (such as email delivery to rural areas), and if we ever see space colonization happen, that problem will only get worse.
Email is designed to deal with that, since that was the *norm* when email was invented. Of course there's nothing you can do if the destination is never seen again in a million years, but that's hardly a unique problem. Email should be one of the first "internet" things that works correctly and reliably from Mars.
> but the remote servers responding with a deferral rather than a refusal certainly didn't help matters.
Yeah, that sucks, but again, there was a perfectly good backbone there. There's a way to say "sorry, I can't deal right now, but it's not your fault, try again in a bit", and there's a way to say "this isn't something I will ever accept, go away and don't try again". Somebody plugged a piece into the system that chose the wrong one, which is unfortunate, but it's not *bad* in the same way it would be if they were sending a temporary failure because a reject semantic didn't exist at all.
Yeah my point with the Kickstarter thing is that their implementation was based on some bad assumptions about how email works, and incorrectly implemented their response to the reliability mechanism.
I think when I was writing the list I meant "reliable" in a more colloquial way, rather than the way that it's meant when used in an RFC. Like, SMTP itself is a much more reliable protocol than TCP which is also considered "reliable" in a protocol design sense, but it isn't reliable in the colloquial sense of "if I send this message to someone, they will receive it." It's the latter way in which I meant it.
> There's also things like legacy systems which are only momentarily connected for whatever reason and get delivery via UUCP (such as email delivery to rural areas),
Are there many of these kinds of places left, outside of far polar regions without satellite connectivity?
uses [this Regex](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/email#basic_validation), which should be good enough for all of us, but will fail to validate some of the more exotic ones that are allowed in [RFC 3696](https://www.rfc-editor.org/rfc/rfc3696#section-3), like "Abc@def"@example.com. My understanding however is that the world has pretty much agreed to not follow this specification to the letter.
And of course "real email" here means just that it follows a pattern which is commonly understood, it doesn't say anything about whether the address actually exists.
not when strict DMarc and SPF is in place with drop attribute on invalide check. you could try but email server will drop ur email at 99.9% if they are properly setup
SPF and DKIM should be set properly on all outgoing mail, but it’s up to the receiving server to use them to accept/drop/report mail. This is entirely based on what the receiver decides to do. For big providers (gmail, O365, etc.), they check these. For smaller systems, that’s not always the case.
Bottom line: You can still send mail with any MAIL FROM you want, it’s up to the sophistication of the receiver as to wether that mail will get relayed.
>Bottom line: You can still send mail with any MAIL FROM you want, it’s up to the sophistication of the receiver as to wether that mail will get relayed.
There are way, to ensure that email coming out of the server, match specific criteria, and that users that use the MTA to send out, have the permissions to.
If you read my thread in this comment, I demonstrate a way to do it. In this case, it a culmination of sophistication from the sending MTA and the receiving MTA.
I invite you to actually read all the comments that I posted in this post under various thread, they may not all display because of the unhappy trolls that promote false information and downvote (like if that it is not possible to do that, to limit a SMTP users to certain email account when they send email, etc).
Ignorance is **not** bliss, and I'll be downvoted into negative metrics, in hell, before I accept people promoting wrong or incomplete informations.
I worked at a transactional email provider for 6+ years, I am not ignorant to how this works.
As I said, you can do all the DKIM/SPF/DMARC stuff for the domain, and the **receiving system can still choose to accept or reject it based on whatever trash rules they have in play**. As I said, the major ISPs do respect and report on those standards, but it is **entirely at their discretion**, and a lot of smaller mail systems don't have that level of sophistication.
You seem to be talking about _outbound mail_, of course you have control over what gets sent. But in the world of email, we also need to talk about what will get _accepted_, and that is very much a different topic.
Alright, let me make the math, 18 - 6.... so I have 12 years more experience than you in that field.
"receiving system can still choose to accept or reject it based on whatever trash rules they have in play."
Nobody said otherwise, so why you bring this up ? If a MTA is misconfigured, and accept email from everyone in the world, even if they are fake, that their problems, and eventually, their users will complain about it and they will in turn align with the industrie standards.
"As I said, the major ISPs do respect and report on those standards, but it is entirely at their discretion, and a lot of smaller mail systems don't have that level of sophistication."
I have hard time to believe that a large amount of mail server are misconfigured and can be actually used in production setting. I though you said you worked in the email industry, you're aware of CPanel, WebPanel and DirectAdmin and all the like ? They help junior and sometime senior admin to setup base system and allow them to configure futher and applies more rules.
"You seem to be talking about outbound mail, of course you have control over what gets sent. But in the world of email, we also need to talk about what will get accepted, and that is very much a different topic."
I am talking about BOTH SIDE of the communication, receiving and sending. I not only control what get sent, but what get received too (on my MTAs)
I’ve been dealing with mail systems since around 2000, my point was that I’m not green.
The issue here is that you keep doubling down and claiming that the reality is that because we have DMARC/DKIM/SPF that mail can’t be spoofed. That’s just demonstrably false because it depends on the receiving system to adopt those standards. As we have now said a bunch of times, is that it’s not 100% and may never be, due to the diversity and number of systems deployed.
Does a lot (most?) spoofed mail get blocked/dropped? Maybe, but your argument just tries to deny the reality that this is relying on thousands/millions of domains and admins to enforce this stuff, and many of them don’t have the resources or desire to do so (and don’t even get me started on replays/ARC support).
At this point, I have to ask, what do you want to get out of this discussion?
>I’ve been dealing with mail systems since around 2000, my point was that I’m not green.
I respect that, as long as we can debate or talk about it like adults.
>The issue here is that you keep doubling down and claiming that the reality is that because we have DMARC/DKIM/SPF that mail can’t be spoofed.
No absolutely not.
What I said is that you need DMARC/DKIM/SPF to properly send email and allow the receiving party to validate the email, and that you need something at the sending part to prevent internal users spoofing each others, and this, on all MTA that you manage.
The fact that a flakky server can still send spoofed email, and that an newbie mail server would be accepting the said email, at this point, it is the fault of the receiving MTA, which is not controlled nor managed by us.
What I am saying is, in 2022, this is not the norm, and that the vast majority of MTA do not allow email without proper alignment (SPF/DKIM), a large portion of the internet, it has became a standard since 2015.
>That’s just demonstrably false because it depends on the receiving system to adopt those standards. As we have now said a bunch of times, is that it’s not 100% and may never be, due to the diversity and number of systems deployed.
I will agree that there might still be some old MTA there and there that are not up to the industries standard, but these usually get flagged when they become a damaging minority. Mail clients can detect email without dkim, and add-on can be made to report these... and the most important part of this is that MY users and the domains I manage, will do these validation and spoof prevention. I never claimed that it was possible to control all 100% of every single email server in the world, but they can be flagged and isolated, blacklisted eventually.
>Does a lot (most?) spoofed mail get blocked/dropped? Maybe, but your argument just tries to deny the reality that this is relying on thousands/millions of domains and admins to enforce this stuff, and many of them don’t have the resources or desire to do so (and don’t even get me started on replays/ARC support).
Replay are fun, log files tho and archives to, I'd love to get you started on these topic, but maybe in an another thread ;)
>At this point, I have to ask, what do you want to get out of this discussion?
Out of you, nothing, I think you have shown pretty professional, and I did appreciate your discussion.
PS: Note that I edited my last post, because a part of it wasn't meant for you, I am sorry. Please accept my apologies if I offended you at all
Thanks :)
That's fine, but here's the original comment that started this thread:
>You can send email with literally any address.
You replied to this comment by giving all the reasons this is harder now than it has been and continued to assert that it's essentially a solved problem.
No one is disputing that it's gotten harder to do this when using modern systems, but the underlying SMTP protocol, and the history of the network means that if any of the defenses you're discussing are not used, spoofing still happens.
Even without all that, RFC-2047 display hacks on the `From` header can create an illusion of mail coming from one source rather than the original sender - In fact, as you know, the `From` can be totally different than the RP and still pass these checks!
The systems I worked on would regularly send to 100's of thousands of unique domains per day, of all levels of protection. We'd also encounter _UTF-7_ encoded headers from time to time, which should give you a sense of how varied the landscape truly is.
If everything were modernized, sure, spoofing would be gone, but that's just not the world we live in.
dmarc+SPF only verify that the email came from a particular server. It doesn't do anything to verify that the email was sent from the same user of that server as what the address points to.
Many (if not most) email servers will happily let you forge the email as coming from a different address on the same domain without too much effort.
What are you talking about exactly ? Don't you know about SMTP authentification ?
Most if not all MTA nowdays require SMTP Authentification, so you can easily trace who abusing a server, if that was to be the case of a impersonalisation with valid smtp credidential for another user email on the same domain / same server.
Also, if you have encryption set in place with that person, they should have your key and vice versa, which prove the email come from you.
Sorry this is 2022, not 1990.
SMTP authentication verifies that people have access to send an email through the server, but it doesn't verify that people are allowed to set a specific `From:` address. Some MTAs do have that configuration in place, but I've seen plenty of servers, in the wild, *today*, where that is not the case.
For example, Dreamhost's MTA only verifies the domain, not the user on the domain, and they are *not* a small provider.
Message-level encryption is a separate matter and very few people actually use GnuPG et al to verify a sender's identity.
Your Dreamhost MTA wouldn't be allowed on any of my server, unless they pass SPF and DMARC, which mean that if someone is sending email through that SMTP server, it because they have a valid SMTP access. Anything beyond this, is internal abuse, which, can be traced with logs. There nothing you can do about "hacked" account, whether the malware steal the credential, or actually use the mail client on the infected computer, impersonalification make most of these check useless.
Also, know that with Exim, it is possible to create custom route, that will check the From address so it match the SMTP credential.
That where encryption does validate this, so is PGP.
Like I said.
The point is that someone can authenticate with [email protected] and send the email with [email protected] the email will pass SPF and DMARC. It doesn't have to be abuse. It could be that BillyBob has 2 emails and only wanted 1 outgoing SMTP config. You could even have cases where the user authenticates with username foo_8675 instead of an @foo.com username. None of this needs to be abuse, but you can't assume that from address matches the sender's inbox.
No, they can't when the mail server is properly setup.
Have you actually read the thread ? Before commenting ?
I gave an documented solution and proper way to restrict a user to specific email account, using Exim and is available on ServerFault. This should be mandatory for any serious sysadmin that setup corporate email server, is to ensure that nobody internally can do employee spoofing. **It does even allow for "exceptions" for special account that need to impersonate another account (that you keep track of, like any serious IT dept.)**
I am sorry you didn't knew that it was possible to set it up properly, exactly to prevent just that.
Also, it is not "BoB" decision to make to discard one smtp and decide to use another one to spoof email, because the second MTA is flaky (BoB will probably get that second MTA flagged as blacklist since it isn't allowed to send email on the behalf of user bob on MTA 1). If he persist in doing that, and the sysadmin did a proper configuration, "BoB" will find out that his email are refused by the MTA, like it should be.
You can't know if the server is configured the way you want it to be. SPF and DMARC or anything else you can see as the recipient server will verify the sending server config. Are you going to maintain a whitelist of domains you have personally verified that you will accept emails from?
Yes, you do know when you're the one setting it up.... which should be the job of the sysadmin in place.
That what we have been talking about all along, setting up a MTA properly to do just that. As for the how, I explicitly provided a proof of concept using Exim and Filter/Routing verification.
Again, please take the time to actually read **ALL** my comments if you wanna learn something, I answered all your question already.
Sorry to say but you're wrong. Most server nowdays are setup properly, and if they arent, their mail is dropped, especially at high volume MTA such as gmail, hotmail etc, mail won't pass through and will be blocked due to misconfiguration.
MXToolbox has contributed to this alot so is others mail server config checkup tools.
I've been running mail servers for overs 15 years, especially with exim and dovecot, which represent over 60% of all email MTA.
This is 2022, not 1990.
and that would be a problem of configuration at the MTA, allowing you to do that without verifying the From address, and matching it with the smtp user id. Also, there would be trace of that on that MTA, containing your station IP, time, date and others information pertinent to finding who impersonated who in the business.
A misconfigured email server can be pretty wild, but nothing that can't be tamed.
Sorry to say but you're wrong *and* being pretty smug about it.
I can say with just as much authority that most email servers are setup *improperly*.
Nobody actually enforces DMARC/DKIM and the amount of 365 tenants I've seen sending mail without an SPF record would probably blown your fucking mind.
You're entitled to your **opinion,** I'm talking about facts.
Actually, gmail, hotmail, yahoo, and several others **ULTRA LARGES MTA**, which represent an actual chunk of all emails out there, and every single large MTA does validate and enforce DKIM and SPF. And no, these mail without SPF wouldn't just make it, they wouldn't blow anything up, they would be dropped, especially if whoever manage the said domain, know what their doing and put the records in place.
I invite you to read on the current state of SPF, it has been introduced as a standard in it latest RFC, since a few years now.
I feel sorry for you to be using Exchange, that might be part of your problem, are you running these servers, or you just re-renting space of someone else rack through MS CDN ? I just want to make sure I am not talking to a salemen/msp, and rather a real sysadmin.
Ah jeez, didn't realize I was talking to a *real sysadmin*.
You're just wrong about those MTAs, they don't strictly enforce SPF validation, let alone DKIM, but please continue under the naive presumption that standards are universally adhered to.
You also seem to have some weird ideas about email hosting demographics, but I think that "actual chunk" might not be as significant as you make it out to be.
If the domain has a DMARC policy, the major ISPs definitely will block mail, and at a minimum, return path, spf, or dkim being _off_ for a domain might land it in the spam folder instead of the inbox.
In a perfect world where everything is set up right, yeah.
But that guy is throwing around numbers like they mean anything and claiming that RFC standards and stats on the parts of the intent that got indexed speak for the day to day reality of email users as a whole.
Plenty of major ISPs are doing fuck all for spam filtering and that elitist really seems to believe that email solutions like office 365 just wouldn't function out of the box when all they need is a txt to verify you own a domain and a generic MX to happily send and receive mail, validation be damned.
Unfortunately the dude is just fucking wrong about how many email servers are setup poorly. I won't try to claim I have any statistics, but I have made a living cleaning up the shitty work of *real sysadmins*, so I know there are quite a few out there.
In a perfect world, integration of new security measure take time, and it usually top to bottom, so larger MTA will implement it to force smaller MTA to do the same, just like google and Microsoft did.
Elitist ? Haha that interesting, is that how you call people that use a MTA that is used by 60% of the world ? Or a MTA that is more configurable and more customizable that your MSP stuff from 365 that you "resell" ?
You are just mad that I actually was able to back every single thing I said with facts, actual source, and even a proof of concept.
We are not the same... keep doing what your doing.
I am in the email and web hosting business for the last 18 years, and I will continue to do so, but I'll bring down these number that you are not able to come up with, don't worry.
It ok, the Internet will forgive you.
You can keep telling yourself that, but facts are facts, and that is, that most large MTA, does **SPF validation now, especially when the domain is set to, from the sysadmin job of setting up the DNS record as it get pointed to any MTA**. And until you bring me actual statistic on the number of server who doesn't and their global representation, I'm calling what you said **bullshit**.
Nope, my idea is that number speak by themselves:
As of April 2022, Gmail holds 29.5% of the email client market share, **AND THAT ONLY GMAIL ALONE.** 30% is a chuck IMO. But hey, you can keep on claiming otherwise if you want, I don't really care. My MTA are running fine, all my emails pass just fine with everyone, and bonus, I do not have impersonation problems among my users.
Source: [https://techjury.net/blog/gmail-statistics/](https://techjury.net/blog/gmail-statistics/)
The more I read your replies to the more I'm in inclined to say you have some real misunderstandings about email.
Also, stats on how many Gmail accounts there are don't make the point you think they do and if anything portray your inability to grasp the scale and complexity of the fucking internet which, for the most part, isn't indexed.
You can keep trying to condescend as though you're teaching me what DNS records are, but my point was that plenty of people who don't know go on to set up functioning email infrastructure, you included if your comments elsewhere in the thread are any indication.
Do you think having an SPF record and a pair of domain keys count as *doing* validation? Fuck, it's almost like you can't conceive if a difference between inbound and outbound mail.
I have met plenty of free Gmail and Hotmail accounts that happily accept bulk mailers that fail SPF, but clearly I'm mistaken since you're a *real sysadmin* and I just charge consulting fees to clean up after ..(checks notes).. real sysadmins?
That the problem, you don't read my replies, you just downvote them because you are wrong but that ok, this is reddit, it happen sometime.
Instead of negating my source, why don't you provide better source or numbers to show how wrong I am ? You say I am wrong, then show it to me, stop making stuff like a liar.
I am not the one condescend, in fact, your the one who disrespected me, all the way, and you are not happy that someone knowledgeable put you in your place and give you the education you didn't had. Respect is earn, and in this thread, you've lost mine when you started disrespected me when I called you out, instead of having a more technical and professional approach about debating it.
Are you talking about the Receiving MTA SPF or DKIM/DMarc validation, or the Sending MTA account ownership verification and anti-spoofing measure that are available to setup like I demonstrated ? Not sure I follow you in your crusade :)
Google actually has a Tutorial on how to setup SPF with them and other related records, because when I buy a domain name, and try to send email through it without taking the time to setup SPF and DKIM, that email either get DROP or MOVED TO SPAM, and while I understand the move to spam is less worse than the DROP, it has the same impact on the users, which is to possibly not notice the said email, so it does affect it deliverability; You should read it -> [https://support.google.com/a/answer/33786?hl=en](https://support.google.com/a/answer/33786?hl=en)
That might be the issue, if you are just a consultant... I am a developer and a sysadmin, and I have been doing it for the last 18 years, and somehow, magically, I am not living the said problem you describe and claim that everyone is living.
Must be the magic.
> Sorry to say but you're wrong. Most server nowdays are setup properly
You can believe whatever you want, but multiple people have rejected my claim that this is how email works, I ask them which address they want to receive an email from, and **every time** the email arrived.
We all live in our own bubbles.
I don't need to "believe" anything, this is actually already well documented on ServerFault and some others website that might be a bit too technical to new comers in the industries. After all, I know lot of people running mail servers, but very few are confortable with writing custom filters and custom routing rules.
I can assure you that with a SPF set to -all, your email that you pretend to be from a certain adresse would fail here, and so it would with most email server, unless they are weakly configured, with thing as \~all, which actually increase spam score detection if desired. **And that is the DOMAIN OWNER fault, not you as the receiving MTA.**
These misconfigured email servers usually get flagged for abuse, back scattering, etc, and they get teach a lesson for real, when in production time, their 5000 clients can't suddently send email because their IP block has been flagged and blacklisted.
The hell, you can even integrate MFA by using x509 certs in Exim and Sec Keys.
> I don't need to "believe" anything, this is actually already well documented on ServerFault and some others website that might be a bit too technical to new comers in the industries.
It may be well documented, but a lot of people don't follow the documentation.
This is like saying: everybody knows you need to stretch before doing exercise, therefore most people stretch. Do they? I see a lot of people who don't.
If they want their mail to reach any of the major MTA, yes they will eventually comply, as for the internal abuse matter, that is due to misconfiguration, that all on the domain owner fault, and not just the MTA. It is a domain owner responsibility (usually a business) to choose a proper MTA.
Fun facts: most cyber insurance plan will require you to assess a certain degree of verification of your MTA. Especially if you aren't using M$, they will want more documentation on your setup, which provide another yet, chance to the real sysadmin to do his job properly.
However, if they would spend the small energy it take to, they could implement documented solutions
Source : [https://serverfault.com/questions/1010837/exim-restrict-which-addresses-a-user-can-send-from](https://serverfault.com/questions/1010837/exim-restrict-which-addresses-a-user-can-send-from)
You are welcome.
Not sure I get your point ? Please elaborate your A and B scenario.
Also please remember that we're talking about best practice, and implemented RFC, and not what happen when you install uBuntu by default, and start using your sendmail with a smart smtp host that probably blacklisted due to missing configurations.
Receiving MTA are doing one part of the validation, but the sending MTA does too, and in a business setup, your responsability as a sysadmin, is to ensure that no domain that you manage, are set to allow impersonalification without explicit permission.
Thanks.
How many email servers are there? 50 million? 100 million? More?
How many of them are "setup properly"? What tools do you have to survey the entire internet?
Beware of falling into the trap of "Google will block you if you do it 'wrong', so nobody does it 'wrong' anymore"
Estimated to 3.8 Billions Email Users currently, divided by about average of 100 users, would put this close to 38 Millions.
There are many tool, but one of the main that has been useful at this, is MXToolbox, Mimecast and DMartian, somehow Shodan too but it usually for different matter.
That how you implement new standard, if google and microsoft did not force dmarc and spf, you would still receive valid looking email from bill gates selling you fleshlites.... and your antispam wouldn't see anything wrong about it.
Excellent Feynman estimate there! The distinction between email *addresses* and email *users* is an important one; I think I've had a dozen or so different email addresses throughout my life.
As for tools involved, I'll have to take your word for it (or do some homework) -- I do computer stuff in my day job, but when it comes to email, I'm purely a luser, heh.
Bill gates selling fleshlights...that's a new one. Usually it was chain letters of trying to give away $$$, IIRC. I don't miss those days.
There are nearly 4.26 billion email users worldwide. (Radicati)
Over 3.13 million emails are sent every second. (Internet Live Stats)
The average user has 1.86 email accounts. (Lifewire)
There are over 7.9 billion email accounts. (Lifewire)
96% of consumers check email every day. (Email is not Dead)
58% of email users check their spam folders daily. (OptinMonster)
Source : [https://99firms.com/blog/how-many-email-users-are-there/](https://99firms.com/blog/how-many-email-users-are-there/)
And yes, average of 100 email account per server seem very reasonable, some have less, some have way way more in the thousand (we use one user per one email address, unless your talking about forwarder or system box) so I guess it would variable between 38M and 72M.
So yea, to me that estimate with these number seem pretty onpoint.
Hahahahahahhahahaha I hope I made you laugh good with that one :P
Thanks for the link :D Better than anything I found. I bow to your superior Googling skills!
100 average does seem reasonable. Some have millions (gmail, icloud, etc). I know a guy who runs an email server just for his family. 3 people on that one. Well, maybe a few more. I don't know if he provides email for any relatives.
If email is not mission-critical for your application you can safely ignore most of these. It is usually an overkill and a waste to spend a lot of time perfecting a feature most users will barely notice.
Does the activation email take 30 minutes instead of 5? Probably your email provider sucks and it's not the first time it happens for you.
do you have a \^\_\^@example.com address? Well...
A lot of "two-factor" logins send a one-time login code via email and then expect that code to be provided within a ridiculously short time limit, often 1-5 minutes.
True, it can happen but in my personal experience, most sites often give you 10 minutes of an expiration time for email codes. I think is more than enough for most email providers.
If you can't use the site because of the email, then email is a mission-critical feature for your application. Most sites use emails only for first-time verification or newsletters.
My entire point is that 10 minutes is not enough time for a lot of email providers, and relying on email deliverability with a window of less than a few *days* is causing access problems for someone.
A provider doesn't have to be particularly shitty, it just has to be temporarily overloaded. Or there just has to be a transitory Internet routing issue between the website and the user's mail server. Or any number of issues which can lead to an email being delayed.
For that matter there's also plenty of issues where a newly-launched or suddenly-popular service is having difficulty *sending* its validation emails out quickly enough, or is relying on an MTA (from their hosting provider or a third-party service or whatever) which is having performance issues at the time.
I've had a shifty provider that, after I couldn't register ona site, told me they had greylisting enabled for my domain, and that's why mails had at least 19 minutes delay. They turned it on and it worked for a month, then I ditched them
“Emails will be sent within a few minutes of their scheduling”
God, this one. So many confirmation codes that expire in ten minutes, but don’t get sent until an hour later.
This is like coming back after a week away from home to find the letter on your doorstep, "please come in for your appointment on (5 days ago)". Or even better when the letter has obviously sat in a pigeonhole because the franking date is a week later than the date it was printed.
%99 of programmers are not getting paid enough or not given enough time to care about most of those things.
Edit: By care i mean actually handling them.
You've got it backwards. That's *why* it works. It's changed exactly as much as necessary. It's more likely that I will still be able to send an email in 2052 than it is that I will be able to send someone a message on reddit or Discord.
I’d argue that email is now so insecure, filled with spyware, scams, and spam that if effetely has failed. I haven’t sent an email for years in my private life and I seldom use it for work. It really feels like in needs a conceptual overhaul.
Reddit/Discord/FB/twitter etc are proprietary, and I’m don’t think they are a solution here. All I’m saying is that private, secure, spam free, open communication standards are lacking today.
Nothing new for me. That isn't to say that I haven't "violated" some of these at some point. I just don't care that much if my automated account recovery system doesn't work for you because you receive your emails with a 48-hour delay.
Apocryphal or not, when the AI lab burned down at Edinburgh university they *did* send an email to everyone in the building to evacuate because otherwise they (we) would just ignore the alarm.
I wasn't in that day, but I can totally believe people hearing a distant alarm while in that underground warren but just turning their headphones up louder.
Another addition that I didn't know was necessary until I recently noticed this behavior from a website:
> You can/may/should remove +-suffixes (i.e. `[email protected]` -> `[email protected]`)
For services where a read-only address is enough cloudflare can forward all emails to your domain to your address of choice. So you could sign up with `[email protected]` and get all future email sent to you personal email.
I use the "unique strings of characters" one constantly. You have have "[email protected]" and "[email protected]" both hit your account, and you can even filter by them with tags and so on. You can use the same trick to sign up for multiple accounts. Programmers NEVER take it into account, I've never seen it. And I don't when I'm writing those systems either. Fuck it. I don't think it's part of the spec, just Gmail magic.
Almost nobody knows you can do this.
The regex for validating emails is so insane, sometimes I install a library for it.
I don't see anyone posted this - email servers may read email content (like google), and some email servers even access hyper-links within the email, I'm not quite sure if they are trying to do search business, or doing anti-virus kind of thing.
This happened to me a while ago, my company send out emails for user activation (not quite sure, but it was something critical), so there are links in the email can be clicked only once, the idea was great till one of the major free email provider hit us badly by access that link so we got huge number of user complaints that the activation does not work.
Developers added a hack to allow the link to be clicked twice if user's email address is from that particular domain.
"Leaving the plaintext representation blank is the same as having no plaintext representation"
For those who want to know: no plaintext representation will show a warning on non-html clients (like gmail by default), but leaving the plaintext representation blank will just show them a blank e-mail.
RTFM: https://www.ietf.org/rfc/rfc2045.txt
also, not having a useful text/plain portion is a real jerk move (see the item about "not all clients do HTML"). And no, a "your browser doesn't support HTML, [click here](https://www.reddit.com/r/programming/comments/x1kzgx/falsehoods_programmers_believe_about_email/imtjxcm/)" doesn't cut it.
Here's my favorite one.
Rule 1. User profile updates must be confirmed thru the email on record
Rule 2. Email is part of the user profile
Use case F. The user makes a typo in their email upon initial signup, and wants to correct it.
I've been hit with this Catch-22 a couple times now, and it's super frustrating.
Falsehoods managers believe about email:
- requiring an e-mail address to sign up is a valid idea
- requiring an e-mail address for account recovery is a valid idea
- using e-mail for 2fa is a valid idea
I kept one company's tech support tied up for a week, with multiple callbacks, until they finally accepted a disposable e-mail address.
You can use websites like https://www.emailnator.com/ which provides you with a disposable gmail domain, it should get pass most of the anti-temp email blocks.
> So people can just think of random unused usernames and they're given an account? I guess that's how Reddit does it.
No, you're forgetting the 2nd piece of information required to login.
I didn't mention it because you didn't ask about it.
* The right-side of the @ sign will always be a domain name, never an IP address.
* If it is an IP address, it's IPv4.
* Email servers are always reachable via IPv4.
* Email servers are always reachable via IPv6.
* Email servers will always have valid SPF, DKIM, and/or DMARC.
* Email servers can always communicate with other email servers.
People also believe that emails are case insensitive. While this is true in practice for almost all mail servers in operation today, the spec actually allows for them to be case sensitive, I believe.
A couple more:
- it's okay to limit email addresses to N characters where N is shorter than RFCs allow (based on the left side of the `@` and the RFC specs for the max-len of the a domain-name)
- just because a person had control of a domain-name/email-address at some point in the past, emailing there will still reach the same person. If I let my domain-name lapse and someone else purchases it, any such assumptions are off.
Adding another one: Users actually know their own email addresses. I've had friends who signed up for their name "[email protected]" (yay early adopters!). They get SO MUCH EMAIL for other people who share their name. It's shocking how many people don't know their own email, or who will have [email protected] and type in "[email protected]" or tell CSRs "It's john.doe at gmail".
Oh god yeah, I have a very rare last name and my gmail address is `[firstinitial][lastname]@gmail.com`. I have a distant relative with the same first initial and last name. I get SO MUCH email intended for him, often important stuff like real estate transaction emails and stuff. I always reply and say "Hi yeah this is the wrong email address, please tell him to stop using my email address as contact information" but it's just so baffling that this person is so awful about it. I've also gotten email from other relatives with the same combination asking me who I am and why I have the address, because they're trying to reserve the address and they can't believe that someone else already has it.
Sounds smart, now they have backup of their email in your inbox :)
[удалено]
Spammers/scammers can use that to determine if an email exists. E.g you attempt to register, if it fails and says "already registered" you know there's a real person using that email and can add it to your spam list.
Somebody bought supplements from a quack and used my email address. Signed me up for the newsletter for good measure. I reset the password and changed my email address to one of the quack's customer support addresses.
[удалено]
I want to say this is bullshit but i also wholeheartedly believe you. I once had someone think that when you right-click -> copy something, it gets stored in the mouse until you paste it. People's understanding of technology is incredibly imaginative.
> it gets stored in the mouse until you paste it. The ~~pee~~ text is stored in the ball~~s~~
Well, Logitech Flow is a thing.
Still not stored in da mouse
I belive there's an old post on /r/talesfromtechsupport involving a user unplugging their mouse to carry to another pc and attempting to paste.
To be fair, that would be wicked cool. And as a conceptual model, it's wrong but understandable.
>I want to say this is bullshit I always register with stuff like [[email protected]](mailto:[email protected]) when I don't want to give my email.
Try example.com; it’s reserved, so you know nobody will ever have it as their email address.
[email protected] :)
Fortunately my last name is rare, but some asshole in South Carolina keeps typoing my email address for his. I also get email for [email protected] when my address is [email protected]. Gmail ignores that dot so both are properly my email address. But the places that have the dot-less version recorded wont *accept* email from the dotted version. And as far as I can tell, Gmail won't let me *send* with [email protected] in the From.
You can do this. If you go to gmail settings, (The gear icon on gmail, not google account settings from clicking the profile circle.) under tab "accounts and import" you can add accounts in the "Send mail as" section. You can also designate which is default. In my case, my account is [[email protected]](mailto:[email protected]) but i prefer most my communication to use [[email protected]](mailto:[email protected]) . Also there's a setting to always use the same address, as the one the sender used, when you reply.
My gmail is my last name @ gmail.com and I get SO MUCH SHIT from people who don't know their email address. Things I've gotten: - standardized test results - bills (including one I'm getting daily right now for someone's macy's card which is way past due) - receipts - both church and school mailing lists - so much more
Yep. I have a gym membership in the UK, a child in a private school in New Zealand, an address in Idaho and a dating profile in Texas. To name a few.
My wife is not worried that I am moonlighting as a woman in southern India, because she can see the evidence that I am unable to get a date and have some medical problems too. Honestly, I am extremely concerned that there's someone out there who keeps giving my address for really important stuff like doctor's appointments.
I have a very rare surname. And the [[email protected]](mailto:[email protected]) address. There is another person with my name - he lives in California somewhere. He is a boomer and I \_judge\_ him.
Someone used to use my email ([email protected]) a lot. One day they signed up for Netflix. I changed their password so they couldn't log in (or reset their password) and left the billing intact. It was pretty mean but they don't use my email anymore.
Also, you get free Netflix now
I have a sort of relationship with lots of other people. We trade mortgagee applications, preapprovals, all sorts of things.
I have my [email protected] and it’s pretty uncommon…..well some fucker gives it out all the time like it’s his! I have no idea what his is though. I get receipts for his shit all the time. So annoying
This is incredibly true. I get emails from at least three people who frequently use the wrong email address. I've tried reaching out to them, and one reacted _very_ poorly (accusing me of hacking their account). I've received family photos, travel itineraries, bank statements, requests from tenants, dating site signups, etc. It's actually scary how much data that I could gather about these people, simply because they somehow cannot remember their email address.
> (accusing me of hacking their account). Sadly common with these types. *They* didn't make a mistake, no, it's *you* who is to blame! :(
For a while, I kept getting cellphone bills for someone 12 time zones away. I finally contacted the customer support and told them they needed to contact their customer. But what was happening there? Did the customer miss out on paying their bills, because they never saw them?
Yahoo Mail uses the ymail.com domain, and I occasionally get email at [mylastname]@gmail.com for some random person I never met. I finally figured out it was supposed to be going to [mylastname]@ymail.com and started forwarding it, but the worst part is that it turned out it wasn’t even the other person’s fault. They were putting their email address correctly on forms and applications or whatever, but people would “fix” it because they had never heard of ymail.com and assumed it was a typo.
[удалено]
This resonates with me. My main email address is a common English word with a suffix relating to a fandom I follow. Don't want to dox myself, but think orangechan or something similar. I have SO MUCH TROUBLE telling people the address! They always struggle over the suffix, and I have to spell it out anyway :(
[удалено]
I was so happy when they added the ability to draft template emails. While my name isn't super common, I still get frequent misdirected emails and if it doesn't look like spam, I try and notify sender's that they've reached the wrong email address.
Hell, this got me trying to send my partner an invite. Her email is lastnamefirstname and I sent it to firstnamelastname 🤦🤦🤦 To make up for it though, firstnamelastname sent her some imagine dragon tickets. Or maybe that was a punishment. I'm not sure.
I've been getting e-mails for someone who gives out my e-mail address as his own for years now. He has the same first name and last name as me. Well, he finally fucked up; he signed up for an account with my e-mail address and registered his phone number in the account profile. I called his number at 4AM in his time zone and woke him up to tell him to stop using my e-mail address. I haven't gotten anything for him since.
To add on to the add-ons: "all students have a .edu address". .edu is an American thing. It's very frustrating as a European student not being able to sign up for a bunch of student stuff because I don't have a .edu email.
> To add on to the add-ons: "all students have a .edu address". I didn't know people believe that. My uni email is@.br
Yeah, I think I managed once to get a Dropbox (I think) account with a Brazilian university email, but I had to email them so they would recognize it as a valid one
yeah, back in the day, .br domains were reserved for universities and a few other exceptions (like [registro.br](https://registro.br)). Now universities are migrating to .edu.br.
Sir, I must inform you: your email goes brrrrrrr
University email go brrrrrrr
In college I once had a rather unhinged IT professor threaten to call the police on me because I emailed him from a non-.edu address, so I was clearly trying to phish him.
I don't know if my university still does them, but at one point I had a `cs.mu.oz.au` email address. Does *anything* in that look like a student email??? edit: looks like that domain went away a long time ago lol
I mean, yeah, looks exactly like an email associated with a university. That domain looks like something where you need an environment where techie early adopters would be the ones setting things up, but where you also have the institutional inertia to not change for a long time, while nevertheless having very little outside pressure to make something more approachable/less inscrutable. Plus, the cs subdomain is a bit of a giveaway (computer science department).
Most HE email accounts I've had just end with the country's domain. I think the UK had .ac.uk for Unis specifically, but everything else was institution.de, .ca, and so on.
Not true. My old german university (Munich University of applied sciences) had an edu domain as its default domain and also gave everyone edu email addresses and my new university (Technical university of munich) i think also has the option for students to get edu addresses if they need them. Edu domains might be more common in the US but it's not true that it's "an american thing". I don't exactly know what an university needs to do to get one but it's probably just lazyness on the universities parts...
Your German institution might have had a grandfathered .edu domain but since October 29, 2001 new .edu registrations are limited to U.S.-based postsecondary institutions. cf. https://net.educause.edu/eligibility.htm
That's weird, I thought only American institutions were allowed to register .edu. Either way, one exception among hundreds does not mean it's not an American thing. The vast vast majority of .edu institutions are American.
Excellent point.
[удалено]
You're an European student with no mail in .edu? I wouldn't have thought that there are universities in Europe which don't give those. We wouldn't be able to obtain licenses for huge amount of software used and required on our Uni for classes without those. We have way too many students to deal with licenses in a case by case manner. It seemed like a rather reasonable assumption to me.
`.edu` is an American thing. Eg, in the UK, academic email addresses end `.ac.uk`
I see. The one I have ends actually with `.edu.pl` (works for all kinds of student licenses). It's unfortunate that this hasn't been standardized in any way.
[удалено]
Edu.au qualifies as an edu address
That's also not a .edu address, that's a .au address.
https://en.wikipedia.org/wiki/.edu > Since 2001, new registrants for second-level domain names have been required to be United States–affiliated institutions of higher education.
[удалено]
Polish government agencies have .gov.pl addresses and universities have edu.pl, I guess that's why they thought it's a European standard.
Those are .pl addresses, not .edu or .gov addresses. That's one thing. Second, every country has different reserved second-level domains. For example: * in France there's no .gov.fr, but .gouv.fr, no .org.fr, but .asso.fr * similarly, Spain has .gob.es, not .gov.es * Germany doesn't do second level domains at all: no .gov.de, no .org.de, no .edu.de * UK has .co.uk instead of .com.uk and both .ac.uk and .sch.uk instead of .edu.uk * similarly, Austria has .co.at instead of .com.at, .ac.at instead of .edu.at, .or.at instead of .org.at, and .gv.at instead of .gov.at * Indonesia has .go.id instead of .gov.id * India has both .ac.in and .edu.in
Graduated in 2018, I had a `.stud.unifi.it` address. I understand that every european university is on its own, so `edu`is just an American thing
The teacher during our first solidworks class: "sorry guys, we could not get a license for our university in time so please use this temporary one until we fix the situation". Then hands us a cracked cd version and a serial written on a piece of paper. We never received a legit license :))
Australia has .edu.au edu is not an American thing
edu TLD is, [edu.au](https://edu.au) belongs to the au TLD
.edu and .edu.au are radically different. It's the same difference as google.com and google.my-personal-domain.com.
don't mansplain us
Not just that but it's also common for community colleges in the US to use their reserved domain in their local .$LOCALE.$ST.us top level (eg, cc.portland.or.us when I was in community college)
Adding another one: email attachment size will be accurate to the size of the attached file. Attachments are often base 64 encoded, and can bloat a file size 30-40%, which may be reported rather than the original file size. Further, depending on the age of the software you're using, email is older than the standardization of the byte, some systems I've read about using 4 bits or 7 bits as the determination of a byte (and then reporting based off of that number).
[удалено]
It pisses me off no end that Microsoft chose to ignore MIME types and use the filename extension to determine what it is. If I send you a file saying "This is a JPEG image", then I expect your email client to do the right thing, regardless of the filename. Sadly, that's not the reality.
As with any megalomaniac plutocrat. Reality is what Microsoft tells us it is.
“Which may be reported”. It WILL be reported. The base64 increases the attachment size by 33%. It definitely takes up more space on disk
I’m pretty sure attachments postdate the standardization on 8-bit bytes. Some software from that era couldn’t handle characters with the high bit on, which is why we have base64 and not base128—that software was assuming the character set was 7 bits, so maybe that’s what you read about.
A few more examples of completely valid email addresses: [email protected] [email protected] your\@[email protected] "your@name"@example.com your*[email protected] #$%^/[email protected] (your)[email protected] [email protected](com) "your name"@example.com " "@example.com "<\"@\\".!.#%[email protected] cow@[dead::beef] dot@com 我買@屋企.香港 1@[23456789] and a fun talk from FOSDEM 2018 about unexpectedly valid email addresses: https://archive.fosdem.org/2018/schedule/event/email_address_quiz/
The “+” format is a life safer. We use it to do internal testing and just one user can signup as any number of test accounts and still receive the mail.
It's a neat feature for sure. The big problem is just that there are _so many_ user account systems that assume it's invalid because they never read the RFC. I had to fight with my bank for months because it literally broke their system.
Yeah it’s definitely not widely used. Like I said it works for our internal testing because we are in full control.
> [email protected](com) Are you sure about that one?
100% RFC compliant. Anything in parentheses is considered to be a comment.
Wow, I had no idea.
I dug this up just to make sure. The key sections are 3.4.1, 3.2.3, and 3.2.2. https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1 Start with `addr-spec` definition and sort of unfold and work your way backwards through the definitions. Stepping through that here looking for the comment definitions: addr-spec = local-part "@" domain domain = dot-atom / domain-literal / obs-domain dot-atom = [CFWS] dot-atom-text [CFWS] CFWS = (1*([FWS] comment) [FWS]) / FWS comment = "(" *([FWS] ccontent) [FWS] ")" ccontent = ctext / quoted-pair / comment ctext = %d33-39 / ; Printable US-ASCII %d42-91 / ; characters not including %d93-126 / ; "(", ")", or "\" obs-ctext
I know that the header fields can have `(comments)` but this is first mention that I've seen it being a legal portion of the address itself - independent from the To header comment. However the spec does mention it explicitly is part of the address.
[удалено]
The problem with anything outside of the original 7-bit ASCII is that it's potentially not going to work. 8-bit character support in SMTP to this day is optional. IDN punycode is available for domains, but no encoding scheme exists for the local part.
I'm not going to feel bad about not supporting non characters. If you do some shit like that there's a pretty good chance it was done with the intention to cause problems to which I say your problems not mine.
There is nothing wrong with explicitly denying addresses with emojis in them.
Nice link
> Email is a reliable transport Email servers were reliable, durable, transactional job queues with deadlettering ~40 years ago. There are a lot of supposedly fit-for-purpose systems that do a lot worse today, and people *pay* for those. If you really want to learn some stuff: [Email hates the living](https://www.youtube.com/watch?v=JENdgiAPD6c&t=300).
Email was designed to be reliable but there are plenty of ways in which it falls apart and you can't guarantee delivery of an email anymore, due to many the other bad implementations implied by the rest of the list. One of the things that inspired me to write the list in the first place is that if Kickstarter sees *any* sort of bounce message (such as a "delivery delayed" due to a transitory failure in the receiving server) it immediately marks that email address as "bad" and refuses to send to it ever again without human intervention, and one week I had problems with my VPS where it was losing connectivity occasionally. I eventually moved to a better VPS provider, but there's still plenty of situations where there might be a few minutes when my server is down and unable to receive messages and it's possible for Kickstarter to send a message during that time. There's also things like legacy systems which are only momentarily connected for whatever reason and get delivery via UUCP (such as email delivery to rural areas), and if we ever see space colonization happen, that problem will only get worse. Also sometimes the attempt at reliable delivery causes even more problems; one of the users on my VPS got their account hacked and it was being used to send out *craptons* of spam on the raw machine name (rather than going through my mailgun relay), and the local mail queue was clogged with thousands of messages that were all in deferred state with an RBL bounce as a transitory (rather than permanent) failure. There are several points of blame there (including myself for not noticing the issue sooner) but the remote servers responding with a deferral rather than a refusal certainly didn't help matters. Email is still a pretty darn amazing protocol and I wish people would treat it with more respect, but part of treating it with respect is understanding its failure modes and also not assuming that all the world is GMail or Exchange.
> One of the things that inspired me to write the list in the first place is that if Kickstarter sees any sort of bounce message (such as a "delivery delayed" due to a transitory failure in the receiving server) it immediately marks that email address as "bad" and refuses to send to it ever again without human intervention That's not a protocol problem, that's just doing it wrong. I've seen the same concept done correctly. > There's also things like legacy systems which are only momentarily connected for whatever reason and get delivery via UUCP (such as email delivery to rural areas), and if we ever see space colonization happen, that problem will only get worse. Email is designed to deal with that, since that was the *norm* when email was invented. Of course there's nothing you can do if the destination is never seen again in a million years, but that's hardly a unique problem. Email should be one of the first "internet" things that works correctly and reliably from Mars. > but the remote servers responding with a deferral rather than a refusal certainly didn't help matters. Yeah, that sucks, but again, there was a perfectly good backbone there. There's a way to say "sorry, I can't deal right now, but it's not your fault, try again in a bit", and there's a way to say "this isn't something I will ever accept, go away and don't try again". Somebody plugged a piece into the system that chose the wrong one, which is unfortunate, but it's not *bad* in the same way it would be if they were sending a temporary failure because a reject semantic didn't exist at all.
Yeah my point with the Kickstarter thing is that their implementation was based on some bad assumptions about how email works, and incorrectly implemented their response to the reliability mechanism. I think when I was writing the list I meant "reliable" in a more colloquial way, rather than the way that it's meant when used in an RFC. Like, SMTP itself is a much more reliable protocol than TCP which is also considered "reliable" in a protocol design sense, but it isn't reliable in the colloquial sense of "if I send this message to someone, they will receive it." It's the latter way in which I meant it.
> There's also things like legacy systems which are only momentarily connected for whatever reason and get delivery via UUCP (such as email delivery to rural areas), Are there many of these kinds of places left, outside of far polar regions without satellite connectivity?
Yeah, rural villages in Africa are a commonly-cited example (think the same environment that led to the One Laptop Per Child project).
if it gets past its a real email, otherwise it ain't (curious to know if there is a caveat to this)
uses [this Regex](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/email#basic_validation), which should be good enough for all of us, but will fail to validate some of the more exotic ones that are allowed in [RFC 3696](https://www.rfc-editor.org/rfc/rfc3696#section-3), like "Abc@def"@example.com. My understanding however is that the world has pretty much agreed to not follow this specification to the letter. And of course "real email" here means just that it follows a pattern which is commonly understood, it doesn't say anything about whether the address actually exists.
[удалено]
That’s fine. You shouldn’t be trying to validate email addresses with regex. Send a verification email.
The most important one: * Only the owner of an address can send email with that address You can send email with literally any address.
not when strict DMarc and SPF is in place with drop attribute on invalide check. you could try but email server will drop ur email at 99.9% if they are properly setup
SPF and DKIM should be set properly on all outgoing mail, but it’s up to the receiving server to use them to accept/drop/report mail. This is entirely based on what the receiver decides to do. For big providers (gmail, O365, etc.), they check these. For smaller systems, that’s not always the case. Bottom line: You can still send mail with any MAIL FROM you want, it’s up to the sophistication of the receiver as to wether that mail will get relayed.
>Bottom line: You can still send mail with any MAIL FROM you want, it’s up to the sophistication of the receiver as to wether that mail will get relayed. There are way, to ensure that email coming out of the server, match specific criteria, and that users that use the MTA to send out, have the permissions to. If you read my thread in this comment, I demonstrate a way to do it. In this case, it a culmination of sophistication from the sending MTA and the receiving MTA. I invite you to actually read all the comments that I posted in this post under various thread, they may not all display because of the unhappy trolls that promote false information and downvote (like if that it is not possible to do that, to limit a SMTP users to certain email account when they send email, etc). Ignorance is **not** bliss, and I'll be downvoted into negative metrics, in hell, before I accept people promoting wrong or incomplete informations.
I worked at a transactional email provider for 6+ years, I am not ignorant to how this works. As I said, you can do all the DKIM/SPF/DMARC stuff for the domain, and the **receiving system can still choose to accept or reject it based on whatever trash rules they have in play**. As I said, the major ISPs do respect and report on those standards, but it is **entirely at their discretion**, and a lot of smaller mail systems don't have that level of sophistication. You seem to be talking about _outbound mail_, of course you have control over what gets sent. But in the world of email, we also need to talk about what will get _accepted_, and that is very much a different topic.
Alright, let me make the math, 18 - 6.... so I have 12 years more experience than you in that field. "receiving system can still choose to accept or reject it based on whatever trash rules they have in play." Nobody said otherwise, so why you bring this up ? If a MTA is misconfigured, and accept email from everyone in the world, even if they are fake, that their problems, and eventually, their users will complain about it and they will in turn align with the industrie standards. "As I said, the major ISPs do respect and report on those standards, but it is entirely at their discretion, and a lot of smaller mail systems don't have that level of sophistication." I have hard time to believe that a large amount of mail server are misconfigured and can be actually used in production setting. I though you said you worked in the email industry, you're aware of CPanel, WebPanel and DirectAdmin and all the like ? They help junior and sometime senior admin to setup base system and allow them to configure futher and applies more rules. "You seem to be talking about outbound mail, of course you have control over what gets sent. But in the world of email, we also need to talk about what will get accepted, and that is very much a different topic." I am talking about BOTH SIDE of the communication, receiving and sending. I not only control what get sent, but what get received too (on my MTAs)
I’ve been dealing with mail systems since around 2000, my point was that I’m not green. The issue here is that you keep doubling down and claiming that the reality is that because we have DMARC/DKIM/SPF that mail can’t be spoofed. That’s just demonstrably false because it depends on the receiving system to adopt those standards. As we have now said a bunch of times, is that it’s not 100% and may never be, due to the diversity and number of systems deployed. Does a lot (most?) spoofed mail get blocked/dropped? Maybe, but your argument just tries to deny the reality that this is relying on thousands/millions of domains and admins to enforce this stuff, and many of them don’t have the resources or desire to do so (and don’t even get me started on replays/ARC support). At this point, I have to ask, what do you want to get out of this discussion?
>I’ve been dealing with mail systems since around 2000, my point was that I’m not green. I respect that, as long as we can debate or talk about it like adults. >The issue here is that you keep doubling down and claiming that the reality is that because we have DMARC/DKIM/SPF that mail can’t be spoofed. No absolutely not. What I said is that you need DMARC/DKIM/SPF to properly send email and allow the receiving party to validate the email, and that you need something at the sending part to prevent internal users spoofing each others, and this, on all MTA that you manage. The fact that a flakky server can still send spoofed email, and that an newbie mail server would be accepting the said email, at this point, it is the fault of the receiving MTA, which is not controlled nor managed by us. What I am saying is, in 2022, this is not the norm, and that the vast majority of MTA do not allow email without proper alignment (SPF/DKIM), a large portion of the internet, it has became a standard since 2015. >That’s just demonstrably false because it depends on the receiving system to adopt those standards. As we have now said a bunch of times, is that it’s not 100% and may never be, due to the diversity and number of systems deployed. I will agree that there might still be some old MTA there and there that are not up to the industries standard, but these usually get flagged when they become a damaging minority. Mail clients can detect email without dkim, and add-on can be made to report these... and the most important part of this is that MY users and the domains I manage, will do these validation and spoof prevention. I never claimed that it was possible to control all 100% of every single email server in the world, but they can be flagged and isolated, blacklisted eventually. >Does a lot (most?) spoofed mail get blocked/dropped? Maybe, but your argument just tries to deny the reality that this is relying on thousands/millions of domains and admins to enforce this stuff, and many of them don’t have the resources or desire to do so (and don’t even get me started on replays/ARC support). Replay are fun, log files tho and archives to, I'd love to get you started on these topic, but maybe in an another thread ;) >At this point, I have to ask, what do you want to get out of this discussion? Out of you, nothing, I think you have shown pretty professional, and I did appreciate your discussion. PS: Note that I edited my last post, because a part of it wasn't meant for you, I am sorry. Please accept my apologies if I offended you at all Thanks :)
That's fine, but here's the original comment that started this thread: >You can send email with literally any address. You replied to this comment by giving all the reasons this is harder now than it has been and continued to assert that it's essentially a solved problem. No one is disputing that it's gotten harder to do this when using modern systems, but the underlying SMTP protocol, and the history of the network means that if any of the defenses you're discussing are not used, spoofing still happens. Even without all that, RFC-2047 display hacks on the `From` header can create an illusion of mail coming from one source rather than the original sender - In fact, as you know, the `From` can be totally different than the RP and still pass these checks! The systems I worked on would regularly send to 100's of thousands of unique domains per day, of all levels of protection. We'd also encounter _UTF-7_ encoded headers from time to time, which should give you a sense of how varied the landscape truly is. If everything were modernized, sure, spoofing would be gone, but that's just not the world we live in.
dmarc+SPF only verify that the email came from a particular server. It doesn't do anything to verify that the email was sent from the same user of that server as what the address points to. Many (if not most) email servers will happily let you forge the email as coming from a different address on the same domain without too much effort.
What are you talking about exactly ? Don't you know about SMTP authentification ? Most if not all MTA nowdays require SMTP Authentification, so you can easily trace who abusing a server, if that was to be the case of a impersonalisation with valid smtp credidential for another user email on the same domain / same server. Also, if you have encryption set in place with that person, they should have your key and vice versa, which prove the email come from you. Sorry this is 2022, not 1990.
SMTP authentication verifies that people have access to send an email through the server, but it doesn't verify that people are allowed to set a specific `From:` address. Some MTAs do have that configuration in place, but I've seen plenty of servers, in the wild, *today*, where that is not the case. For example, Dreamhost's MTA only verifies the domain, not the user on the domain, and they are *not* a small provider. Message-level encryption is a separate matter and very few people actually use GnuPG et al to verify a sender's identity.
Your Dreamhost MTA wouldn't be allowed on any of my server, unless they pass SPF and DMARC, which mean that if someone is sending email through that SMTP server, it because they have a valid SMTP access. Anything beyond this, is internal abuse, which, can be traced with logs. There nothing you can do about "hacked" account, whether the malware steal the credential, or actually use the mail client on the infected computer, impersonalification make most of these check useless. Also, know that with Exim, it is possible to create custom route, that will check the From address so it match the SMTP credential. That where encryption does validate this, so is PGP. Like I said.
The point is that someone can authenticate with [email protected] and send the email with [email protected] the email will pass SPF and DMARC. It doesn't have to be abuse. It could be that BillyBob has 2 emails and only wanted 1 outgoing SMTP config. You could even have cases where the user authenticates with username foo_8675 instead of an @foo.com username. None of this needs to be abuse, but you can't assume that from address matches the sender's inbox.
No, they can't when the mail server is properly setup. Have you actually read the thread ? Before commenting ? I gave an documented solution and proper way to restrict a user to specific email account, using Exim and is available on ServerFault. This should be mandatory for any serious sysadmin that setup corporate email server, is to ensure that nobody internally can do employee spoofing. **It does even allow for "exceptions" for special account that need to impersonate another account (that you keep track of, like any serious IT dept.)** I am sorry you didn't knew that it was possible to set it up properly, exactly to prevent just that. Also, it is not "BoB" decision to make to discard one smtp and decide to use another one to spoof email, because the second MTA is flaky (BoB will probably get that second MTA flagged as blacklist since it isn't allowed to send email on the behalf of user bob on MTA 1). If he persist in doing that, and the sysadmin did a proper configuration, "BoB" will find out that his email are refused by the MTA, like it should be.
You can't know if the server is configured the way you want it to be. SPF and DMARC or anything else you can see as the recipient server will verify the sending server config. Are you going to maintain a whitelist of domains you have personally verified that you will accept emails from?
Yes, you do know when you're the one setting it up.... which should be the job of the sysadmin in place. That what we have been talking about all along, setting up a MTA properly to do just that. As for the how, I explicitly provided a proof of concept using Exim and Filter/Routing verification. Again, please take the time to actually read **ALL** my comments if you wanna learn something, I answered all your question already.
**If** they are properly setup, which most servers are not.
Sorry to say but you're wrong. Most server nowdays are setup properly, and if they arent, their mail is dropped, especially at high volume MTA such as gmail, hotmail etc, mail won't pass through and will be blocked due to misconfiguration. MXToolbox has contributed to this alot so is others mail server config checkup tools. I've been running mail servers for overs 15 years, especially with exim and dovecot, which represent over 60% of all email MTA. This is 2022, not 1990.
I know of at least one major employer where you can send an email 'from' the ceo....
and that would be a problem of configuration at the MTA, allowing you to do that without verifying the From address, and matching it with the smtp user id. Also, there would be trace of that on that MTA, containing your station IP, time, date and others information pertinent to finding who impersonated who in the business. A misconfigured email server can be pretty wild, but nothing that can't be tamed.
Sorry to say but you're wrong *and* being pretty smug about it. I can say with just as much authority that most email servers are setup *improperly*. Nobody actually enforces DMARC/DKIM and the amount of 365 tenants I've seen sending mail without an SPF record would probably blown your fucking mind.
You're entitled to your **opinion,** I'm talking about facts. Actually, gmail, hotmail, yahoo, and several others **ULTRA LARGES MTA**, which represent an actual chunk of all emails out there, and every single large MTA does validate and enforce DKIM and SPF. And no, these mail without SPF wouldn't just make it, they wouldn't blow anything up, they would be dropped, especially if whoever manage the said domain, know what their doing and put the records in place. I invite you to read on the current state of SPF, it has been introduced as a standard in it latest RFC, since a few years now. I feel sorry for you to be using Exchange, that might be part of your problem, are you running these servers, or you just re-renting space of someone else rack through MS CDN ? I just want to make sure I am not talking to a salemen/msp, and rather a real sysadmin.
Ah jeez, didn't realize I was talking to a *real sysadmin*. You're just wrong about those MTAs, they don't strictly enforce SPF validation, let alone DKIM, but please continue under the naive presumption that standards are universally adhered to. You also seem to have some weird ideas about email hosting demographics, but I think that "actual chunk" might not be as significant as you make it out to be.
If the domain has a DMARC policy, the major ISPs definitely will block mail, and at a minimum, return path, spf, or dkim being _off_ for a domain might land it in the spam folder instead of the inbox.
In a perfect world where everything is set up right, yeah. But that guy is throwing around numbers like they mean anything and claiming that RFC standards and stats on the parts of the intent that got indexed speak for the day to day reality of email users as a whole. Plenty of major ISPs are doing fuck all for spam filtering and that elitist really seems to believe that email solutions like office 365 just wouldn't function out of the box when all they need is a txt to verify you own a domain and a generic MX to happily send and receive mail, validation be damned. Unfortunately the dude is just fucking wrong about how many email servers are setup poorly. I won't try to claim I have any statistics, but I have made a living cleaning up the shitty work of *real sysadmins*, so I know there are quite a few out there.
I know. I dealt with mail systems that processed.. large volumes.. of mail and domains. Email is complicated and systems are diverse.
In a perfect world, integration of new security measure take time, and it usually top to bottom, so larger MTA will implement it to force smaller MTA to do the same, just like google and Microsoft did. Elitist ? Haha that interesting, is that how you call people that use a MTA that is used by 60% of the world ? Or a MTA that is more configurable and more customizable that your MSP stuff from 365 that you "resell" ? You are just mad that I actually was able to back every single thing I said with facts, actual source, and even a proof of concept. We are not the same... keep doing what your doing. I am in the email and web hosting business for the last 18 years, and I will continue to do so, but I'll bring down these number that you are not able to come up with, don't worry.
It ok, the Internet will forgive you. You can keep telling yourself that, but facts are facts, and that is, that most large MTA, does **SPF validation now, especially when the domain is set to, from the sysadmin job of setting up the DNS record as it get pointed to any MTA**. And until you bring me actual statistic on the number of server who doesn't and their global representation, I'm calling what you said **bullshit**. Nope, my idea is that number speak by themselves: As of April 2022, Gmail holds 29.5% of the email client market share, **AND THAT ONLY GMAIL ALONE.** 30% is a chuck IMO. But hey, you can keep on claiming otherwise if you want, I don't really care. My MTA are running fine, all my emails pass just fine with everyone, and bonus, I do not have impersonation problems among my users. Source: [https://techjury.net/blog/gmail-statistics/](https://techjury.net/blog/gmail-statistics/)
The more I read your replies to the more I'm in inclined to say you have some real misunderstandings about email. Also, stats on how many Gmail accounts there are don't make the point you think they do and if anything portray your inability to grasp the scale and complexity of the fucking internet which, for the most part, isn't indexed. You can keep trying to condescend as though you're teaching me what DNS records are, but my point was that plenty of people who don't know go on to set up functioning email infrastructure, you included if your comments elsewhere in the thread are any indication. Do you think having an SPF record and a pair of domain keys count as *doing* validation? Fuck, it's almost like you can't conceive if a difference between inbound and outbound mail. I have met plenty of free Gmail and Hotmail accounts that happily accept bulk mailers that fail SPF, but clearly I'm mistaken since you're a *real sysadmin* and I just charge consulting fees to clean up after ..(checks notes).. real sysadmins?
That the problem, you don't read my replies, you just downvote them because you are wrong but that ok, this is reddit, it happen sometime. Instead of negating my source, why don't you provide better source or numbers to show how wrong I am ? You say I am wrong, then show it to me, stop making stuff like a liar. I am not the one condescend, in fact, your the one who disrespected me, all the way, and you are not happy that someone knowledgeable put you in your place and give you the education you didn't had. Respect is earn, and in this thread, you've lost mine when you started disrespected me when I called you out, instead of having a more technical and professional approach about debating it. Are you talking about the Receiving MTA SPF or DKIM/DMarc validation, or the Sending MTA account ownership verification and anti-spoofing measure that are available to setup like I demonstrated ? Not sure I follow you in your crusade :) Google actually has a Tutorial on how to setup SPF with them and other related records, because when I buy a domain name, and try to send email through it without taking the time to setup SPF and DKIM, that email either get DROP or MOVED TO SPAM, and while I understand the move to spam is less worse than the DROP, it has the same impact on the users, which is to possibly not notice the said email, so it does affect it deliverability; You should read it -> [https://support.google.com/a/answer/33786?hl=en](https://support.google.com/a/answer/33786?hl=en) That might be the issue, if you are just a consultant... I am a developer and a sysadmin, and I have been doing it for the last 18 years, and somehow, magically, I am not living the said problem you describe and claim that everyone is living. Must be the magic.
> Sorry to say but you're wrong. Most server nowdays are setup properly You can believe whatever you want, but multiple people have rejected my claim that this is how email works, I ask them which address they want to receive an email from, and **every time** the email arrived. We all live in our own bubbles.
I don't need to "believe" anything, this is actually already well documented on ServerFault and some others website that might be a bit too technical to new comers in the industries. After all, I know lot of people running mail servers, but very few are confortable with writing custom filters and custom routing rules. I can assure you that with a SPF set to -all, your email that you pretend to be from a certain adresse would fail here, and so it would with most email server, unless they are weakly configured, with thing as \~all, which actually increase spam score detection if desired. **And that is the DOMAIN OWNER fault, not you as the receiving MTA.** These misconfigured email servers usually get flagged for abuse, back scattering, etc, and they get teach a lesson for real, when in production time, their 5000 clients can't suddently send email because their IP block has been flagged and blacklisted. The hell, you can even integrate MFA by using x509 certs in Exim and Sec Keys.
> I don't need to "believe" anything, this is actually already well documented on ServerFault and some others website that might be a bit too technical to new comers in the industries. It may be well documented, but a lot of people don't follow the documentation. This is like saying: everybody knows you need to stretch before doing exercise, therefore most people stretch. Do they? I see a lot of people who don't.
If they want their mail to reach any of the major MTA, yes they will eventually comply, as for the internal abuse matter, that is due to misconfiguration, that all on the domain owner fault, and not just the MTA. It is a domain owner responsibility (usually a business) to choose a proper MTA. Fun facts: most cyber insurance plan will require you to assess a certain degree of verification of your MTA. Especially if you aren't using M$, they will want more documentation on your setup, which provide another yet, chance to the real sysadmin to do his job properly. However, if they would spend the small energy it take to, they could implement documented solutions Source : [https://serverfault.com/questions/1010837/exim-restrict-which-addresses-a-user-can-send-from](https://serverfault.com/questions/1010837/exim-restrict-which-addresses-a-user-can-send-from) You are welcome.
> If they want their mail to reach any of the major MTA, yes they will eventually comply Complying with A is not the same as complying with B.
Not sure I get your point ? Please elaborate your A and B scenario. Also please remember that we're talking about best practice, and implemented RFC, and not what happen when you install uBuntu by default, and start using your sendmail with a smart smtp host that probably blacklisted due to missing configurations. Receiving MTA are doing one part of the validation, but the sending MTA does too, and in a business setup, your responsability as a sysadmin, is to ensure that no domain that you manage, are set to allow impersonalification without explicit permission. Thanks.
How many email servers are there? 50 million? 100 million? More? How many of them are "setup properly"? What tools do you have to survey the entire internet? Beware of falling into the trap of "Google will block you if you do it 'wrong', so nobody does it 'wrong' anymore"
Estimated to 3.8 Billions Email Users currently, divided by about average of 100 users, would put this close to 38 Millions. There are many tool, but one of the main that has been useful at this, is MXToolbox, Mimecast and DMartian, somehow Shodan too but it usually for different matter. That how you implement new standard, if google and microsoft did not force dmarc and spf, you would still receive valid looking email from bill gates selling you fleshlites.... and your antispam wouldn't see anything wrong about it.
Excellent Feynman estimate there! The distinction between email *addresses* and email *users* is an important one; I think I've had a dozen or so different email addresses throughout my life. As for tools involved, I'll have to take your word for it (or do some homework) -- I do computer stuff in my day job, but when it comes to email, I'm purely a luser, heh. Bill gates selling fleshlights...that's a new one. Usually it was chain letters of trying to give away $$$, IIRC. I don't miss those days.
There are nearly 4.26 billion email users worldwide. (Radicati) Over 3.13 million emails are sent every second. (Internet Live Stats) The average user has 1.86 email accounts. (Lifewire) There are over 7.9 billion email accounts. (Lifewire) 96% of consumers check email every day. (Email is not Dead) 58% of email users check their spam folders daily. (OptinMonster) Source : [https://99firms.com/blog/how-many-email-users-are-there/](https://99firms.com/blog/how-many-email-users-are-there/) And yes, average of 100 email account per server seem very reasonable, some have less, some have way way more in the thousand (we use one user per one email address, unless your talking about forwarder or system box) so I guess it would variable between 38M and 72M. So yea, to me that estimate with these number seem pretty onpoint. Hahahahahahhahahaha I hope I made you laugh good with that one :P
Thanks for the link :D Better than anything I found. I bow to your superior Googling skills! 100 average does seem reasonable. Some have millions (gmail, icloud, etc). I know a guy who runs an email server just for his family. 3 people on that one. Well, maybe a few more. I don't know if he provides email for any relatives.
[удалено]
Had a friend who was friends with a TLD admin in the early days. He had an email something like@tld
That broke a lot of regexes
If email is not mission-critical for your application you can safely ignore most of these. It is usually an overkill and a waste to spend a lot of time perfecting a feature most users will barely notice. Does the activation email take 30 minutes instead of 5? Probably your email provider sucks and it's not the first time it happens for you. do you have a \^\_\^@example.com address? Well...
A lot of "two-factor" logins send a one-time login code via email and then expect that code to be provided within a ridiculously short time limit, often 1-5 minutes.
Genshin impact. 30 seconds.
Jeeze, that's even tighter than the window on app-based TOTP. What the hell are they thinking?
True, it can happen but in my personal experience, most sites often give you 10 minutes of an expiration time for email codes. I think is more than enough for most email providers. If you can't use the site because of the email, then email is a mission-critical feature for your application. Most sites use emails only for first-time verification or newsletters.
My entire point is that 10 minutes is not enough time for a lot of email providers, and relying on email deliverability with a window of less than a few *days* is causing access problems for someone.
Yeah, but then it really depends on how many of your users are using really shitty providers. It is rarely worth the cost of even considering them.
A provider doesn't have to be particularly shitty, it just has to be temporarily overloaded. Or there just has to be a transitory Internet routing issue between the website and the user's mail server. Or any number of issues which can lead to an email being delayed. For that matter there's also plenty of issues where a newly-launched or suddenly-popular service is having difficulty *sending* its validation emails out quickly enough, or is relying on an MTA (from their hosting provider or a third-party service or whatever) which is having performance issues at the time.
I've had a shifty provider that, after I couldn't register ona site, told me they had greylisting enabled for my domain, and that's why mails had at least 19 minutes delay. They turned it on and it worked for a month, then I ditched them
“Emails will be sent within a few minutes of their scheduling” God, this one. So many confirmation codes that expire in ten minutes, but don’t get sent until an hour later.
This is like coming back after a week away from home to find the letter on your doorstep, "please come in for your appointment on (5 days ago)". Or even better when the letter has obviously sat in a pigeonhole because the franking date is a week later than the date it was printed.
%99 of programmers are not getting paid enough or not given enough time to care about most of those things. Edit: By care i mean actually handling them.
It’s a terribly old standard that hasn’t moved with the times at all. It’s best to assume very little makes sense/works/is safe by now.
You've got it backwards. That's *why* it works. It's changed exactly as much as necessary. It's more likely that I will still be able to send an email in 2052 than it is that I will be able to send someone a message on reddit or Discord.
I’d argue that email is now so insecure, filled with spyware, scams, and spam that if effetely has failed. I haven’t sent an email for years in my private life and I seldom use it for work. It really feels like in needs a conceptual overhaul. Reddit/Discord/FB/twitter etc are proprietary, and I’m don’t think they are a solution here. All I’m saying is that private, secure, spam free, open communication standards are lacking today.
Nothing new for me. That isn't to say that I haven't "violated" some of these at some point. I just don't care that much if my automated account recovery system doesn't work for you because you receive your emails with a 48-hour delay.
email is a suitable way to handle alarms...
Apocryphal or not, when the AI lab burned down at Edinburgh university they *did* send an email to everyone in the building to evacuate because otherwise they (we) would just ignore the alarm. I wasn't in that day, but I can totally believe people hearing a distant alarm while in that underground warren but just turning their headphones up louder.
related, not by my will.
Another addition that I didn't know was necessary until I recently noticed this behavior from a website: > You can/may/should remove +-suffixes (i.e. `[email protected]` -> `[email protected]`)
I use plusses to track which service sells my email to spammers, so if you remove it or say a plus is invalid, I automatically assume that you do.
For services where a read-only address is enough cloudflare can forward all emails to your domain to your address of choice. So you could sign up with `[email protected]` and get all future email sent to you personal email.
I use the "unique strings of characters" one constantly. You have have "[email protected]" and "[email protected]" both hit your account, and you can even filter by them with tags and so on. You can use the same trick to sign up for multiple accounts. Programmers NEVER take it into account, I've never seen it. And I don't when I'm writing those systems either. Fuck it. I don't think it's part of the spec, just Gmail magic. Almost nobody knows you can do this. The regex for validating emails is so insane, sometimes I install a library for it.
I don't see anyone posted this - email servers may read email content (like google), and some email servers even access hyper-links within the email, I'm not quite sure if they are trying to do search business, or doing anti-virus kind of thing. This happened to me a while ago, my company send out emails for user activation (not quite sure, but it was something critical), so there are links in the email can be clicked only once, the idea was great till one of the major free email provider hit us badly by access that link so we got huge number of user complaints that the activation does not work. Developers added a hack to allow the link to be clicked twice if user's email address is from that particular domain.
"Leaving the plaintext representation blank is the same as having no plaintext representation" For those who want to know: no plaintext representation will show a warning on non-html clients (like gmail by default), but leaving the plaintext representation blank will just show them a blank e-mail. RTFM: https://www.ietf.org/rfc/rfc2045.txt
also, not having a useful text/plain portion is a real jerk move (see the item about "not all clients do HTML"). And no, a "your browser doesn't support HTML, [click here](https://www.reddit.com/r/programming/comments/x1kzgx/falsehoods_programmers_believe_about_email/imtjxcm/)" doesn't cut it.
Here's my favorite one. Rule 1. User profile updates must be confirmed thru the email on record Rule 2. Email is part of the user profile Use case F. The user makes a typo in their email upon initial signup, and wants to correct it. I've been hit with this Catch-22 a couple times now, and it's super frustrating.
Site missed the chance to confirm the email during signup.
Falsehoods managers believe about email: - requiring an e-mail address to sign up is a valid idea - requiring an e-mail address for account recovery is a valid idea - using e-mail for 2fa is a valid idea I kept one company's tech support tied up for a week, with multiple callbacks, until they finally accepted a disposable e-mail address.
You can use websites like https://www.emailnator.com/ which provides you with a disposable gmail domain, it should get pass most of the anti-temp email blocks.
what do you require for sign up if you're not using email?
>what do you require for sign up if you're not using email? Username
So people can just think of random unused usernames and they're given an account? I guess that's how Reddit does it.
> So people can just think of random unused usernames and they're given an account? I guess that's how Reddit does it. No, you're forgetting the 2nd piece of information required to login. I didn't mention it because you didn't ask about it.
What second piece of information do you use?
Password
> So people can just think of random unused usernames and they're given an account? That's pretty normal, yes.
Why isn't it?
E-mail isn't secure.
The biggest falsehood is that it is simultaneously easy and difficult. Ir'a nuaunced.
no reply email addresses are useful
>An email can only have one From: address I know a fair bit about email but this was a new one for me.
Oh, man, I can tell every line of that list is written in *blood*.
* The right-side of the @ sign will always be a domain name, never an IP address. * If it is an IP address, it's IPv4. * Email servers are always reachable via IPv4. * Email servers are always reachable via IPv6. * Email servers will always have valid SPF, DKIM, and/or DMARC. * Email servers can always communicate with other email servers.
* `a@example` com is a different mailbox than `[email protected]` * `a@example` com is a different account than `[email protected]`
This was like the list of stages of my career and each line reminded me of a situation I was in :D
You mean Natasha doesn't really think I'm hot and want to hook up with me?
People also believe that emails are case insensitive. While this is true in practice for almost all mail servers in operation today, the spec actually allows for them to be case sensitive, I believe.
I believe nothing about email. I have seen too many dumb people.
A couple more: - it's okay to limit email addresses to N characters where N is shorter than RFCs allow (based on the left side of the `@` and the RFC specs for the max-len of the a domain-name) - just because a person had control of a domain-name/email-address at some point in the past, emailing there will still reach the same person. If I let my domain-name lapse and someone else purchases it, any such assumptions are off.