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

From: 'Toerless Eckert' <[email-masked]>
Date: Wed, 21 Jul 2021 20:41:01 +0200

Let me add emailcore

On Wed, Jul 21, 2021 at 05:29:54PM +0000, STARK, BARBARA H wrote:
> Hi Toerless,
> I'm fairly sure the problem lies within the AT&T email systems, which are very convoluted (for security reasons).

Thanks.

> 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 ;-).

emailcore is working on RFC5321bis. 

Hardening protocol state machineries against broken peers
is IMHO extremely important, for sond principles such as
"be lenient in what you accept and diligent in what you send",
or providing good error diagnostics.

This particular part of the SMTP state machinery is one which
doesn't do either. In my memory almost the only.

I do suspect ATTs broken sender would continue to send
the message body after the ".", but the SMTP peer will
just interpret that as broken SMTP. If that is the case,
it should be possible to use an expanded SMTP state machinery
with such an error recognition, even if just heuristic.

And heuristic is good enough. It just takes few correctly
triggeed error email notifications from the heuristic to get bugs
like this fixed over the years, especially when the error email
generated was easy to understand.

I would be happy to suggest a heuristic if emailcore was
willing to think about adding this as an item to fix
for draft-ietf-emailcore-rfc5321bis.

Worst case, you might need to send more emails with
the problematic 76 characters to test the theory ;-)

Cheers
    Toerless

> I'm not particularly incented to try to fix the AT&T email issue because such things always involve going through a Tier 1 "help" desk that will want to invasively take control of my laptop to try to "fix" my problem (because all problems are on users' local machines, of course). They may break something that works, while doing this. I would then have to convince this person half a world a way to please escalate. It's not worth it to me, so I'm going to leave it here.
> Barbara
>  
> > Thanks, Barbara, but i can still not make out heds or tails
> > (adding Glen and John)
> > 
> > a) Was the bug now fixed ? Aka: when you repeat this, will it work now ?
> > 
> > b) Whether fixed or not, which piece of software is the culprit ?
> > 
> > AFAIK:
> > 
> > The "old" behavior you refer to is the standard SMTP end-of-mail-data
> > "<CRLF>.<CRLF>" behavior of 1982 RFC821 section 3.1  that must go
> > along with the transparency procedure of section 4.5.2. Current
> > SMTP RFC5321 does not change this behavior.
> > 
> > So, you can see why i am curious about any software having a bug
> > about a procedure that has been used in gazillions (too many to count)
> > of emails since 1982.
> > 
> > The way you describe it sounds as if an Exchane server must be
> > speaking SMTP, and it is folding long lines AFTER performing the
> > SMTP transparency fixup, which is the wrong order.
> > 
> > The only SMTP server/message-receiver side issue i can think of is
> > confusion introduced when going beyond ASCII about what constitutes
> > a ".". RFC5321 hints at this, but does not explain the breaking workflow.
> > 
> > Cheers
> >     Toerless
> > 
> > On Wed, Jul 21, 2021 at 03:33:35PM +0000, STARK, BARBARA H wrote:
> > > Following up for those who may be curious...
> > > I did email the support team with copies of the sent and received versions of
> > emails. Glen correctly diagnosed the problem.
> > > My email contained a line with exactly 76 characters, with last character ".",
> > and followed by carriage return. Apparently, my Exchange server wrapped this
> > line at 75 characters to put that "." all by itself on a line (with the carriage
> > return).
> > > The emails I received were being truncated directly before that ".".
> > > This is a known bizarre issue.
> > >
> > https://urldefense.com/v3/__https://unix.stackexchange.com/questions/38156
> > /sendmail-procmail-exchange-truncating-
> > mail__;!!BhdT!y4NKbaHihIlZDD_qjVaDSgFEXbVqZpRI00Bnmb63dTsUcMAY6vSUA
> > QCQI5jkaA$
> > >
> > > The answer there explains that
> > > " - Exchange: on accepting a piece of mail for delivery, it appears to reformat
> > a plain text message, encoding and wrapping its lines to 75 characters.
> > >    - sendmail: An old (but known) behaviour was being followed in that mail
> > with a bare period on a line was interpreted as end-of-message and then
> > delivered, effectively truncating the actual mail body."
> > >
> > > Well, I feel better now.
> > >
> > > Barbara
> > >
> > > > Do you have an example date / message id of such an email ?
> > > >
> > > > Does the dnssd email archive have the email untruncated but only group
> > > > members
> > > > report that it was truncated on their end, or is it also truncated on the
> > > > list archive ?
> > > >
> > > > I had once email recently from an AD via draft-alias and WG expander,
> > > > which arrived truncated on my side, but made it untruncated to
> > > > the WG alias.
> > > >
> > > > Alas, i have not been able to track thast one down, even
> > > > through it was a mayor issue for me (AD review of one of my drafts
> > > > that i received truncated. Imagine how i felt when the AD told me:
> > > > why did you stop fixing nits after 25% of my review... ;-))
> > > >
> > > > Cheers
> > > >     Toerless
> > > >
> > > > On Fri, Jul 16, 2021 at 02:50:51PM +0000, STARK, BARBARA H wrote:
> > > > > My emails (to [email-masked]) are suddenly being strangely truncated. I've
> > > > never seen this before. Is anyone else experiencing this, or experienced this
> > in
> > > > the past?
> > > > > Barbara
> > > > >
> > > > > ___________________________________________________________
> > > > > Tools-discuss mailing list - [email-masked]
> > > > > This list is for discussion, not for action requests or bug reports.
> > > > > * Report datatracker and mailarchive bugs to: datatracker-
> > [email-masked]
> > > > > * Report tools.ietf.org bugs to: [email-masked]
> > > > > * Report all other bugs or issues to: [email-masked]
> > > > > List info (including how to Unsubscribe):
> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tools-
> > > > discuss__;!!BhdT!y69XSrVx9_N0CqsoYvkdc4xaLGtXfH6kh-
> > > > qvbmUhVIgNfw0yBw6GXgb2ZApVtA$
> > > >
> > > > --
> > > > ---
> > > > [email-masked]
> > 
> > --
> > ---
> > [email-masked]

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 22 Jul 2021 00:24:57 +0200

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\' <[email-masked]> said:
> 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

-- 
---
[email-masked]