Re: [Tools-discuss] emails being truncated

['Toerless Eckert' <[e-mail]>]

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 [e-mail]) 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 - [e-mail]
> > > > > This list is for discussion, not for action requests or bug reports.
> > > > > * Report datatracker and mailarchive bugs to: datatracker-
> > [e-mail]
> > > > > * Report tools.ietf.org bugs to: [e-mail]
> > > > > * Report all other bugs or issues to: [e-mail]
> > > > > List info (including how to Unsubscribe):
> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tools-
> > > > discuss__;!!BhdT!y69XSrVx9_N0CqsoYvkdc4xaLGtXfH6kh-
> > > > qvbmUhVIgNfw0yBw6GXgb2ZApVtA$
> > > >
> > > > --
> > > > ---
> > > > [e-mail]
> > 
> > --
> > ---
> > [e-mail]

-- 
---
[e-mail]