1. Forum
  2. Usenet
  3. COMP.MAIL.SENDMAIL

  • Sendmail Support for BDAT/Chunking?

    From Andreas S. Kerber@21:1/5 to All on Thu Oct 26 10:35:45 2023
    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."

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Andreas S. Kerber on Thu Oct 26 12:05:41 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Sun Nov 12 12:00:58 2023
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Marco Moock on Sun Nov 12 11:08:30 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Marco Moock on Mon Nov 13 01:17:45 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Mon Nov 13 09:43:57 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Marco Moock on Mon Nov 13 10:54:20 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Mon Nov 13 21:33:28 2023
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Marco Moock on Tue Nov 14 05:08:31 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Tue Nov 14 11:32:21 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)