I can confirm just about all of this because of a recent job in this space. Whatever you do, do not do two way sync with Google's CardDAV servers or you will end up with a lot of lost data.
I wonder if they should even be allowed to call it CardDAV since you'd expect it to actually adhere to the standard.
Google is large enough not to care about this though, as long as it works with their address books on Android phones it is probably good enough for them.
Note that this post seems to be from 2014 and the situation isn't much better today!
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/
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.
“ 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.
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.
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".
'The only "must not" in 8.8 is the prohibition of changing the destination local parts.'
That's not even true. If anyone cares about this they should just read the texts. I'm certainly not going to argue this any further. We're looking at the same page and seeing different words.
It actually says this:
"However, only addresses, local-parts, or domains that match specific local MSA configuration settings should be altered"
In other words, the opposite of what you claim. You can keep banging on this if you find it useful, but I'm not going to read any more of your comments.
According to RFC2119, which defines these terms, "should" and "should not" are recommendations with the caveat that individuals not following said recommendations need to understand the full implications what they are doing.
On the other hand, the words "must" and "must not" specify absolute requirements and prohibitions of the standard, respectively.
I think the confusion comes from parsing the poorly worded "only X should be altered" which doesn't really make it clear how the "should" applies.
The clear wording would be "... should only alter X" which makes it clear that altering things other than X needs be be done with full understanding of the implications.
I know nothing about these RFCs, but this seems trivial to clear up with a reference to the text. Here's RFC6409 section 8.8: https://tools.ietf.org/html/rfc6409#section-8.8. There is exactly one "MUST NOT" and it looks like it only prohibits what your parent said it does.
There seems to be an idea floating around that anything at all is permitted under the RFC for MSAs unless it is specifically prohibited using the phrase "must not", regardless of context and other guidance in this RFP and the other RFPs that refer to it. Perhaps this is true. I have a sincere question for anyone holding this opinion: would Google be in compliance if their software altered the message body by adding the sentence "Google is the best search engine ever." here and there, at random? If not, why not, exactly?
In Poland it was standard to add ads as mail footers among homegrown free providers. Some still do. If they don't have sold ads they just advertise themselves.
Made me hate pretty much all footers, especially the bloated corporate ones.
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.
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.
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.
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.
I doubt their poor compliance to standards is done maliciously. I'm guessing it's more about needing some service, finding an open standard or code that does what they need, making changes that are convenient for them, then moving on to the next project.
If not malice then willful harm through inaction. The service should be shut down or fixed.
From the Article:
> "Google’s CardDAV server silently wipes out all kinds of data it doesn’t care about."
How is this "bad" functionality treated differently than issues found and publicized after a 90-day-count-down in the security disclosure universe?
They likely have known about their noncompliance, and they must know the impact; they are a technically savvy group. Plus I presume they have the financial resources to fix this with a year-to-year rising stock price currently at 1,095.50 USD.
"... moving on to the next project" is irresponsible after unleashing a service which when used correctly WILL corrupt users' data.
Their documentation could probably be more complete, but it does say, for example, that they don't support user defined fields on WebDAV requests.
I suppose they could have opted to not mention CardDAV or the other standards and just published an API called GCard or something like that.
They do mention that interoperating with Apple's operating systems is working, so that may be what determined the subset they care about.
> service which when used correctly WILL corrupt users' data
So that comes back to who gets to define what correct use is? If you follow the Google documentation and are losing data, then I agree with you. They should fix the problem or update the documentation.
We need to change the culture of software development such that this behaviour is considered unprofessional. Perhaps a professional software engineering association might help?
I wonder if they should even be allowed to call it CardDAV since you'd expect it to actually adhere to the standard.
Google is large enough not to care about this though, as long as it works with their address books on Android phones it is probably good enough for them.
Note that this post seems to be from 2014 and the situation isn't much better today!