On Wed, 09 Jan 2019 13:25:43 +0530, Viruthagiri Thirumavalavan said:
Ok what am I missing here? When a server says that "I recognize markdown
format", then the client gonna send markdown messages as it is. I
understand a session can transport multiple messages. But why do you think
it won't work?
OK. 129 people at 37 different .coms that are all hosted on Office365 or
whatever Microsoft is calling that product now send e-mails to 217 people at 94
different .coms that are hosted by Google.
Microsoft bundled all 217 mails into one stream and connects to Google. Google
says "I do markdown". Microsoft squishes 217 emails from a multipart/
alternative that contains dual text/(plain,html) down to text/markdown,
breaking any PGP or S/MIME signatures on the multipart/alternative that just
got squished into one body part.
Google now has 217 e-mails to deliver to users - and of the 94 domains, 37 of
them use a corporate email product that doesn't understand text/markdown and
they really wanted a multipart with plain,html. Another 12 of them are
complaining that Google broke the S/MIME on an e-mail that *needed* to be
digitally signed because it was confirmation of a purchase that involved real
money (nevermind that it was Microsoft that did the squishing, the users always
complain to their own vendor, not the guilty party. And even though the
complaining users *do* understand e-mail enough to say "I can't act on a
purchase confirmation that's not digitally signed and has a big red X on it
because the signature is bad", they don't understand that multiple servers
handled it along the way.
What does the Google server do now?
And as others will confirm, I'm not making this sort of issue up - these sorts
of problems crop up all the time. And no matter how clear you thought you
wrote the RFC, you'll find some vendor who had a crack-addicted chimpanzee
writing code that manages to Get It Totally Wrong.
Consider this snippet from my .procmailrc that I had to put in to be able to
open e-mails from IBM:
# Lotus Notes is a boil on the buttocks of e-mail.,...
:0 hwf
*^X-Mailer:.*(IBM|Lotus) Notes
| sed -e 's/boundary="=_alternative /boundary="=_alternative /' -e
's/boundary="=_mixed /boundary="=_mixed /' -e 's/boundary="=_related
/boundary="=_related /'
Not only did they put blanks in the boundary separator for multipart, but they
had *two* blanks in the declaration in the RFC822 message headers, but only one
blank in the actual separators between body parts in the mail body.
And this was a problem for me because the emails that wouldn't open were from
an IBM support team working on a Sev 1 (system is totally down) issue with a
server of mine on a $1.2M project.
I never understood how that product managed to interoperate with the rest of
the world with that bug in it.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp