Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Sendmail Support for BDAT/Chunking?
143 views
Skip to first unread message
Andreas S. Kerber
Oct 26, 2023, 6:35:48 AM10/26/23
to
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."
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."
Claus Aßmann
Oct 26, 2023, 12:05:44 PM10/26/23
to
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
> Is there any chance the BDAT/Chunking support will be added to sendmail?
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
> standards (for example, DomainKeys Identified Mail or DKIM), Office 365 no
> longer removes bare line feeds from messages."
(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,
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.
Marco Moock
Nov 12, 2023, 6:01:02 AM11/12/23
to
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
> Unlikely - there doesn't seem to be any real benefit that would
> outweigh the conversion overhead.
make it mandatory, it will be hard for others not having support for it.
What does the Proofpoint company say about BDAT support?
Claus Aßmann
Nov 12, 2023, 11:08:33 AM11/12/23
to
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
> 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.
and make it mandatory what will others do?
> What does the Proofpoint company say about BDAT support?
Claus Aßmann
Nov 13, 2023, 1:17:48 AM11/13/23
to
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:
> 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.
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.
Marco Moock
Nov 13, 2023, 3:44:01 AM11/13/23
to
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.
> 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.
Claus Aßmann
Nov 13, 2023, 10:54:23 AM11/13/23
to
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?
> > 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.
Can you provide evidence of your claim?
Is this specific to some M$ servers?
Marco Moock
Nov 13, 2023, 3:33:31 PM11/13/23
to
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
> 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?
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?
Claus Aßmann
Nov 14, 2023, 5:08:33 AM11/14/23
to
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.
> > Marco Moock wrote:
> > > So that means what MS does RFC violation again.
> IIRC the normal SMTP DATA command makes usage of CRLF mandatory.
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?
Marco Moock
Nov 14, 2023, 5:32:24 AM11/14/23
to
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
> 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.
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.
0 new messages