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/
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/
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.
The meaning of the whole section is clear, and I stand behind what I wrote.
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".
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.
On the other hand, the words "must" and "must not" specify absolute requirements and prohibitions of the standard, respectively.
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.
They wouldn't be a good server to use, but they'd be one compliant to the specification.
--> What this tells you is that abiding by the spec is not everything, it just sets minimum interoperability guarantees.
Made me hate pretty much all footers, especially the bloated corporate ones.
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.