Re: [Emailcore] [Tools-discuss] emails being truncated

[Toerless Eckert <[e-mail]>]

Removing tools-discuss.

John,

As far as i see it, your "its a known failure of the other side, go tell microsoft"
approach has not succeeded to get rid of the issue. 

Hence i suggested to think about how SMTP spec could be improved by
hardened it against misbehaving peers, specify how it can be more lenient
and or provide diagnostics.

IMHO, this particular case is a day 1 weak part of SMTP because
there is no specification for detecting/diagnosing misbehavior.
That is much better in most other error cases in SMTP:

Getting truncated emails without any error diagnostics when only one
SMTP peer is wrong is a weak protocol behavior.

If you do not want to improve SMTP but only hold a grudge aainst
Microsoft, consider the following:

I have seen more than one occurrances of router CLI commands called
"vendorX-bug-foo-workaround", and guess what - that public shaming
did help for vendorX to fix those bugs a lot faster then it would have
happened otherwise.

Diagnostic emails would effectively result in very much the same
type of public shaming. Much better than any of us going to Microsoft
and complaining about it could do.

Cheers
    Toerless

P.S.: and yes, i also see hat none of this would likely help
Barbara directly given how the next peer after what even calls
itself outlook in its received line is yet another enterprise SMTP
peer equally likely not to be bug fixed in an agile way. As i said, 
this is about what should be considered good for hardening the protocol.

On Wed, Jul 21, 2021 at 05:21:21PM -0400, John Levine wrote:
> It appears that \'Toerless Eckert\' <[e-mail]> said:
> >> I don't think this is a problem that can be solve by IETF.
> >
> >Let me disagree!
> >
> >It is of course very frustrating to see such bugs in deployments
> >for a spec from 1982 (RFC821/RFC5321). But if the problem does happen in
> >a large enterprise as ATT, it likely happens elsewhere too,
> >and after 43 years its clear it will not go away by itself:
> >
> >I suspect that after 43 years this is not even bad old code, but
> >badly written "recent" SMTP code. SMTP sending looks from the outset so
> >simple, many attempt to just re-implement it as few lines of
> >code in their app and of course miss out on details. I know
> >i did (statue of limitations for me ;-).
> 
> An interesting guess, but clearly wrong, since it's still a well known bug
> in Microsoft Exchange.
> 
> How about if you pop up to Redmond, explain to Microsoft what they're doing
> wrong, and let us know what they say?
> 
> R's,
> John

-- 
---
[e-mail]