ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] [Proposal] 250-MARKDOWN

2019-01-09 02:42:54
You are right Mr. Kletnieks.

My proposal would break with stuffs like DKIM, PGP etc

Thanks for taking your time and explaining all those stuffs.

On Wed, Jan 9, 2019 at 2:00 PM <valdis(_dot_)kletnieks(_at_)vt(_dot_)edu> wrote:

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.



-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp