7 ms·

I was under the impression that literally anything goes on the left side of the @. It’s all up to the individual mail server

by eric_h 9y ago

AndrewSnow 9y ago
IIRC, not quite literally, but pretty close. The email RFCs in general tend to be much less constrained than one might expect.
- tajen 9y ago
  Yup. Even spaces are allowed if you put double quotes around the local part: “Kevin Spacey”@example.com. It’s really surprising, there’s very little that can be verified if you strictly follow the RFC.
  - MichaelGG 9y ago
    This is a common issue with text based formats and ietf/RFCs. HTTP allows comments in some headers. And allows line breaks: H: hi Mom Is the same as H: hi Mom Bets on how many http clients and servers get this right? Without losing speed? My guess is when you're not responsible for ensuring compatibility or having to deal with writing robust, fast, code, the temptation to be cute with your format overtakes things.
    - loeg 9y ago
      I expect all commonly used HTTP clients (Chrome, Firefox, IE, even libcurl) and servers (Apache, Nginx, does IIS still exist?) get this right.
      - MichaelGG 9y ago
        I, too, would expect that the most common pieces of software with massive amounts of engineering time invested get it right (but almost certainly with a performance hit). But I'd be unsurprised to find that one doesn't handle the http parsing spec correctly somewhere. The issue is that such a spec is entirely unneeded and overly complicated. No benefit, only downsides. And for something as simple as basic parsing rules! Not even getting into anything that should be difficult.
  - spc476 9y ago
    And comments: Muhammad.(I am the greatest) Ali @(the)Vegas.WBA (an example lifted directly from RFC-822, apparently written by a madman in love with 70s parser theory).
  - zbentley 9y ago
    > there’s very little that can be verified if you strictly follow the RFC. That's not correct. You can reliably, completely validate all email addresses . . . by sending an email to them containing information that can be used to confirm the owner's identity. All together now: the MTA is the only source of "is it valid or not" for email addresses.
avar 9y ago
Even things at the right side of the @ are up to the E-Mail server. You can send an E-mail to @gmail.com or @GMAIL.COM and Google could be routing it differently. It'll resolve the same in DNS, but what the user typed will be encoded in E-Mail headers, and you could route differently depending on whether it's upper-case, mixed-case or whatever.
- written 9y ago
  Not true, domain part is case insensitive by the standard. Server can decide for non-standard behavior, but that would be foolish.
  - thrill 9y ago
    The name part, per the standard, is case sensitive. However, some organizations I get email from canonicalize it to all caps - and one even removes the dots(!) and all-cap it, which for my gmail I have a filter that sends all non-dotted email to spam, since 90% of my spam is non-dotted. Since that particular email was important and I'd just happened to notice it in spam, I checked the capitalization change and called them and even managed to get through to speak with their email manager. He absolutely insisted I was wrong about it mattering and said they wouldn't change it.
    - chrsstrm 9y ago
      Changing case could be a co's lazy way of checking for existing accounts. In a perfect world they would store the input as-is and also use a lower or upper func on the indexed col. I suppose if they are verifying emails with their users and not seeing a big drop-off in verified accounts, they probably don't care to be too exact. Removing dots from the user portion is pretty shitty though.
  - avar 9y ago
    The domain being in any case for the purpose of delivery is part of the standard, but there's nothing I know if which would prohibit you from implementing local delivery and routing in any way you want once the mail is accepted.

I was under the impression that literally anything goes on the left side of the @. It’s all up to the individual mail server

by eric_h 9y ago

I was under the impression that literally anything goes on the left side of the @. It’s all up to the individual mail server

AndrewSnow 9y ago

IIRC, not quite literally, but pretty close. The email RFCs in general tend to be much less constrained than one might expect.

tajen 9y ago
Yup. Even spaces are allowed if you put double quotes around the local part: “Kevin Spacey”@example.com. It’s really surprising, there’s very little that can be verified if you strictly follow the RFC.
- MichaelGG 9y ago
  This is a common issue with text based formats and ietf/RFCs. HTTP allows comments in some headers. And allows line breaks: H: hi Mom Is the same as H: hi Mom Bets on how many http clients and servers get this right? Without losing speed? My guess is when you're not responsible for ensuring compatibility or having to deal with writing robust, fast, code, the temptation to be cute with your format overtakes things.
  - loeg 9y ago
    I expect all commonly used HTTP clients (Chrome, Firefox, IE, even libcurl) and servers (Apache, Nginx, does IIS still exist?) get this right.
    - MichaelGG 9y ago
      I, too, would expect that the most common pieces of software with massive amounts of engineering time invested get it right (but almost certainly with a performance hit). But I'd be unsurprised to find that one doesn't handle the http parsing spec correctly somewhere. The issue is that such a spec is entirely unneeded and overly complicated. No benefit, only downsides. And for something as simple as basic parsing rules! Not even getting into anything that should be difficult.
- spc476 9y ago
  And comments: Muhammad.(I am the greatest) Ali @(the)Vegas.WBA (an example lifted directly from RFC-822, apparently written by a madman in love with 70s parser theory).
- zbentley 9y ago
  > there’s very little that can be verified if you strictly follow the RFC. That's not correct. You can reliably, completely validate all email addresses . . . by sending an email to them containing information that can be used to confirm the owner's identity. All together now: the MTA is the only source of "is it valid or not" for email addresses.

avar 9y ago

Even things at the right side of the @ are up to the E-Mail server. You can send an E-mail to @gmail.com or @GMAIL.COM and Google could be routing it differently. It'll resolve the same in DNS, but what the user typed will be encoded in E-Mail headers, and you could route differently depending on whether it's upper-case, mixed-case or whatever.

written 9y ago
Not true, domain part is case insensitive by the standard. Server can decide for non-standard behavior, but that would be foolish.
- thrill 9y ago
  The name part, per the standard, is case sensitive. However, some organizations I get email from canonicalize it to all caps - and one even removes the dots(!) and all-cap it, which for my gmail I have a filter that sends all non-dotted email to spam, since 90% of my spam is non-dotted. Since that particular email was important and I'd just happened to notice it in spam, I checked the capitalization change and called them and even managed to get through to speak with their email manager. He absolutely insisted I was wrong about it mattering and said they wouldn't change it.
  - chrsstrm 9y ago
    Changing case could be a co's lazy way of checking for existing accounts. In a perfect world they would store the input as-is and also use a lower or upper func on the indexed col. I suppose if they are verifying emails with their users and not seeing a big drop-off in verified accounts, they probably don't care to be too exact. Removing dots from the user portion is pretty shitty though.
- avar 9y ago
  The domain being in any case for the purpose of delivery is part of the standard, but there's nothing I know if which would prohibit you from implementing local delivery and routing in any way you want once the mail is accepted.