Is there any chance the BDAT/Chunking support will be added to sendmail?
Our "friends" at MS365 have changed have changed something:

https://learn.microsoft.com/en-us/exchange/troubleshoot/email-delivery/ndr/fix-error-code-550-5-6-11-in-exchange-online
{...}
"Microsoft 365 and Office 365 used to remove bare line feeds from messages to enable delivery to older email servers that didn't support SMTP Chunking and the BDAT command. In an effort to better support security standards (for example, DomainKeys Identified Mail or DKIM), Office 365 no longer removes bare line feeds from messages."

Their super great advice is:

"Upgrade the destination email server to a newer version (or different email server software) that supports the SMTP BDAT command"
{...}
"Email servers that supports the SMTP BDAT command can accept messages with bare line feeds. Most modern email servers support BDAT; however, some free and older email servers don't support BDAT."

Andreas S. Kerber wrote:
> Is there any chance the BDAT/Chunking support will be added to sendmail?

Unlikely - there doesn't seem to be any real benefit that would
outweigh the conversion overhead. Of course, someone could write
a good patch and submit it to the maintainers (or post it here).

> Our "friends" at MS365 have changed have changed something:

> Chunking and the BDAT command. In an effort to better support security
> standards (for example, DomainKeys Identified Mail or DKIM), Office 365 no
> longer removes bare line feeds from messages."

Hmm... interesting but mostly bogus explanation... there is some
(security?) problem, but that is still under "embargo".

> "Email servers that supports the SMTP BDAT command can accept messages
> with bare line feeds. Most modern email servers support BDAT; however,

Why does anyone want to support "bare line feeds"? The RFCs are
clear about this (e.g., RFC 2821, 2.3.7) -- not that RFCs would
matter to companies like M$.

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Am 26.10.2023 um 12:05:41 Uhr schrieb Claus Aßmann:

> Unlikely - there doesn't seem to be any real benefit that would
> outweigh the conversion overhead.

The interesting question is how MS and Google will handle this. If they
make it mandatory, it will be hard for others not having support for it.
What does the Proofpoint company say about BDAT support?

Marco Moock wrote:

> The interesting question is how MS and Google will handle this. If they
> make it mandatory, it will be hard for others not having support for it.

If M$ and Google come up with a way to get paid for e-mail
and make it mandatory what will others do?

> What does the Proofpoint company say about BDAT support?

You could ask them and post the answer.

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Marco Moock wrote:

> The interesting question is how MS and Google will handle this. If they
> make it mandatory, it will be hard for others not having support for it.

BTW: RFC 3030:

5) Servers that offer the BDAT extension MUST continue to support the
regular SMTP DATA command. Clients are free to use DATA to
transfer appropriately encoded to servers that support the
CHUNKING extension if they wish to do so.

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Am 13.11.2023 um 01:17:45 Uhr schrieb Claus Aßmann:

> BTW: RFC 3030:
>
> 5) Servers that offer the BDAT extension MUST continue to support
> the regular SMTP DATA command. Clients are free to use DATA to
> transfer appropriately encoded to servers that support the
> CHUNKING extension if they wish to do so.

So that means what MS does RFC violation again.

Marco Moock wrote:

> > 5) Servers that offer the BDAT extension MUST continue to support
> > the regular SMTP DATA command. Clients are free to use DATA to
> > transfer appropriately encoded to servers that support the
> > CHUNKING extension if they wish to do so.

> So that means what MS does RFC violation again.

Do you mean M$ "MTA"s do not support DATA anymore?
Can you provide evidence of your claim?
Is this specific to some M$ servers?

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Am 13.11.2023 um 10:54:20 Uhr schrieb Claus Aßmann:

> Marco Moock wrote:
>
> > > 5) Servers that offer the BDAT extension MUST continue to
> > > support the regular SMTP DATA command. Clients are free to use
> > > DATA to transfer appropriately encoded to servers that support the
> > > CHUNKING extension if they wish to do so.
>
> > So that means what MS does RFC violation again.
>
> Do you mean M$ "MTA"s do not support DATA anymore?
> Can you provide evidence of your claim?
> Is this specific to some M$ servers?

https://learn.microsoft.com/en-us/exchange/troubleshoot/email-delivery/ndr/fix-error-code-550-5-6-11-in-exchange-online

It seems to affect messages that use LF as a newline character instead
of CRLF.
IIRC the normal SMTP DATA command makes usage of CRLF mandatory.

In the past Exchange replaced them by CRLF, but that breaks DKIM.

Is my guess right that using LF is simply a problem in the composing
software?
Then that means everything they did was simply a workaround for not
fixing stuff at the other end where the message with only LF is being
created in injected.

Is my guess right?

Marco Moock wrote:

> > Marco Moock wrote:

> > > So that means what MS does RFC violation again.

Doesn't look like it - at least not in this context.

> IIRC the normal SMTP DATA command makes usage of CRLF mandatory.

See the fine RFCs, e.g., 5321

2.3.8. Lines

Lines consist of zero or more data characters terminated by the
sequence ASCII character "CR" (hex value 0D) followed immediately by
ASCII character "LF" (hex value 0A). This termination sequence is
denoted as <CRLF> in this document. Conforming implementations MUST
NOT recognize or generate any other character or character sequence
as a line terminator.

> Is my guess right that using LF is simply a problem in the composing
> software?

Whatever sends "bare LF" is broken - also explained in the RFCs.

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Am 14.11.2023 um 05:08:31 Uhr schrieb Claus Aßmann:

> Marco Moock wrote:
>
> > > Marco Moock wrote:
>
> > > > So that means what MS does RFC violation again.
>
> Doesn't look like it - at least not in this context.
>
> > IIRC the normal SMTP DATA command makes usage of CRLF mandatory.
>
> See the fine RFCs, e.g., 5321
>
> 2.3.8. Lines
>
> Lines consist of zero or more data characters terminated by the
> sequence ASCII character "CR" (hex value 0D) followed immediately
> by ASCII character "LF" (hex value 0A). This termination sequence is
> denoted as <CRLF> in this document. Conforming implementations
> MUST NOT recognize or generate any other character or character
> sequence as a line terminator.
>
> > Is my guess right that using LF is simply a problem in the composing
> > software?
>
> Whatever sends "bare LF" is broken - also explained in the RFCs.

So that means MS fixed those messages in the past (breaking DKIM) and
won't do that anymore. As SMTP with DATA command requires CRLF,
non-RFC-conform messages with LF will fail.

So the idea is to use BDAT instead that will accept it. Sounds rather
strange for me instead of fixing the submission software that inserts
LF.