5 ms·

"Google is large enough not to care about this" They also operate "SMTP servers" that violate the applicable RFPs, have done so for many years, and are not con

"Google is large enough not to care about this" They also operate "SMTP servers" that violate the applicable RFPs, have done so for many years, and are not concerned about the potential damage that can result: https://lee-phillips.org/gmailRewriting/ https://lee-phillips.org/gmailRewriting/

NateyJay 9y ago
This does suck, but you can actually use From: aliases if you set them up first in the Gmail interface. You also have to enable two factor auth. Hard to be too mad about spam fighting measures.
- leephillips 9y ago
  Sounds like I need to update my article. Thanks for this information. But note that they are still violating the RFPs, if they rewrite headers for people who fail to jump through these hoops. They can implement their spam protections (if that's the purpose) while remaining compliant by rejecting the emails in question.
  - Aelius 9y ago
    Maybe I've misunderstood something, but if gmail didn't do this, what's to stop me from sending emails that look like they come from your address?
    - leephillips 9y ago
      Nothing. The standard allows you to put anything you want in the From: header. Sometimes I send emails from Santa Claus or God. The envelope information is still there.
    - leephillips 9y ago
      Actually, not "nothing." If the MSA doesn't like this, it is free to reject the email. But not to change its content.
ebikelaw 9y ago
You don’t seem to understand the standards you are complaining about. You are using mail submission, not relaying. RFC5321 specifically says that it does not cover submission, and defers to RFC4409 (3.6.1) which specifically allows From header rewriting (8.8). If you’re going to complain about the standards-compliance of other people's services it’s important to understand the standard first.
- leephillips 9y ago
  I discuss exactly this in the article. I even referred to sec. 8.8 (of the current 6409; 4409 is superseded (but 8.8 is the same)).
  - ebikelaw 9y ago
    Yeah but you don’t seem to really grok it. “ The MSA MAY rewrite local parts and/or domains in the SMTP envelope and, optionally, in address fields of the header, according to local policy.“ Generally MSAs are permitted to do almost anything. Your reading of the RFC which requires MSAs to merely reject instead of modifying messages is not backed by any of the language in the RFC. Essentially, you seem to misunderstand “may” “must” and “should” as used in these documents.
    - leephillips 9y ago
      You're extracting one sentence out of several paragraphs. The following paragraph restricts the permissible rewriting, and Google is going beyond what is permitted. If your interpretation differs from mine, that's fine. I don't think you need to support your view by selective quotations and accusing me of not being aware of what I explicitly dealt with. The meaning of the whole section is clear, and I stand behind what I wrote.
      - ebikelaw 9y ago
        Again, the only thing that seems clear here is that you don't know how to read an RFC. The only "must not" in 8.8 is the prohibition of changing the destination local parts. "must not" appears nowhere else in section 8, and 8 is not strongly prescriptive as it "describes a number of such modifications that are often considered useful". The described modifications are not thought to be exhaustive. Moreover, 5321 describes MSA as "arrangements are private and fall outside the scope of this specification, they are not described here." 5321 does not control MSA and 4409/6409 do not defer to 5321 on any point. 4409/6490 do _refer_ to 5321, of course. There are only 5 MUST NOTs in 6409 and there are zero SHOULD NOTs. The standard permits the MSA to do pretty much anything it wants to do. I think you should begin by reading 2119 "Key words for use in RFCs to Indicate Requirement Levels".
leephillips 9y ago
After considering some of the comments below, I retract my statement that Google is violating the relevant RFPs. They are operating their servers in violation of reasonable user expectations, and potentially causing harm in doing so, but they are still, strictly speaking, in compliance. I plan to update my article to reflect this.

NateyJay 9y ago

This does suck, but you can actually use From: aliases if you set them up first in the Gmail interface. You also have to enable two factor auth. Hard to be too mad about spam fighting measures.

leephillips 9y ago
Sounds like I need to update my article. Thanks for this information. But note that they are still violating the RFPs, if they rewrite headers for people who fail to jump through these hoops. They can implement their spam protections (if that's the purpose) while remaining compliant by rejecting the emails in question.
- Aelius 9y ago
  Maybe I've misunderstood something, but if gmail didn't do this, what's to stop me from sending emails that look like they come from your address?
  - leephillips 9y ago
    Nothing. The standard allows you to put anything you want in the From: header. Sometimes I send emails from Santa Claus or God. The envelope information is still there.
  - leephillips 9y ago
    Actually, not "nothing." If the MSA doesn't like this, it is free to reject the email. But not to change its content.

ebikelaw 9y ago

You don’t seem to understand the standards you are complaining about. You are using mail submission, not relaying. RFC5321 specifically says that it does not cover submission, and defers to RFC4409 (3.6.1) which specifically allows From header rewriting (8.8). If you’re going to complain about the standards-compliance of other people's services it’s important to understand the standard first.

leephillips 9y ago
I discuss exactly this in the article. I even referred to sec. 8.8 (of the current 6409; 4409 is superseded (but 8.8 is the same)).
- ebikelaw 9y ago
  Yeah but you don’t seem to really grok it. “ The MSA MAY rewrite local parts and/or domains in the SMTP envelope and, optionally, in address fields of the header, according to local policy.“ Generally MSAs are permitted to do almost anything. Your reading of the RFC which requires MSAs to merely reject instead of modifying messages is not backed by any of the language in the RFC. Essentially, you seem to misunderstand “may” “must” and “should” as used in these documents.
  - leephillips 9y ago
    You're extracting one sentence out of several paragraphs. The following paragraph restricts the permissible rewriting, and Google is going beyond what is permitted. If your interpretation differs from mine, that's fine. I don't think you need to support your view by selective quotations and accusing me of not being aware of what I explicitly dealt with. The meaning of the whole section is clear, and I stand behind what I wrote.
    - ebikelaw 9y ago
      Again, the only thing that seems clear here is that you don't know how to read an RFC. The only "must not" in 8.8 is the prohibition of changing the destination local parts. "must not" appears nowhere else in section 8, and 8 is not strongly prescriptive as it "describes a number of such modifications that are often considered useful". The described modifications are not thought to be exhaustive. Moreover, 5321 describes MSA as "arrangements are private and fall outside the scope of this specification, they are not described here." 5321 does not control MSA and 4409/6409 do not defer to 5321 on any point. 4409/6490 do _refer_ to 5321, of course. There are only 5 MUST NOTs in 6409 and there are zero SHOULD NOTs. The standard permits the MSA to do pretty much anything it wants to do. I think you should begin by reading 2119 "Key words for use in RFCs to Indicate Requirement Levels".

leephillips 9y ago

After considering some of the comments below, I retract my statement that Google is violating the relevant RFPs. They are operating their servers in violation of reasonable user expectations, and potentially causing harm in doing so, but they are still, strictly speaking, in compliance. I plan to update my article to reflect this.