Alex via Postfix-users:
> Hi,
>
> > Aug 22 01:36:33 iceman postfix-199/smtpd[584336]: connect from
> > > mail-dm6nam04on2133.outbound.protection.outlook.com[40.107.102.133]
> > > Aug 22 01:36:34 iceman postfix-199/smtpd[584336]: A5C98100002D6:
> > > client=mail-dm6nam04on2133.outbound.protection.outlook.com
> > [40.107.102.133]
> > > Aug 22 01:51:36 iceman postfix-199/smtpd[584336]: timeout after BDAT
> > > (3293244 bytes) from
> > > mail-dm6nam04on2133.outbound.protection.outlook.com[40.107.102.133]
> > > Aug 22 01:51:36 iceman postfix-199/smtpd[584336]: disconnect from
> > > mail-dm6nam04on2133.outbound.protection.outlook.com[40.107.102.133]
> > > ehlo=2 starttls=1 mail=1 rcpt=1 bdat=0/1 rset=1 commands=6/7
> > >
> > > I'm seeing quite a large number of those "timeout after BDAT" entries
> > > in my logs, all of which are from different
> > > outbound.protection.outlook.com servers.
> > >
> > > Given the instructions in https://www.postfix.org/BDAT_README.html
> > > I've disabled BDAT support for now, hoping this will alleviate the
> > > problem until I can identify the cause.
> >
> > Questions:
> >
> > - Is there a "firewall-in-the-middle" that "secures" your inbound
> > email streams? That could invalidate the byte count that was sent
> > by outlook.com versus the byte count that was received by Postfix.
> >
>
> No, but this comment and your comment about not generally seeing these
> messages did make me think of a possible local network problem, and after
> updating the kernel and apparently some other packages, the problem appears
> to have resolved itself. Curious that it really only revealed itself with
> Microsoft 365 systems.
BDAT is different than other SMTP commands: the client sends a byte
count for the amount of data that follows the command, and Postfix
will not reply until it has received the number of bytes in the
BDAT command. If that number is somehow made larger in transit,
or if some data bytes are lost in transit, then the BDAT command
will time out.
This session was using TLS, therefore it is unlikely that the bits
were changed after encryption in the SMTP client and before decryption
in the SMTP server (TLS has stronger integrity guarantees than TCP
checksums). It could however be a problem in data compression before
encryption or decompression after decryption. One could work around
that with "tls_ssl_options = NO_COMPRESSION".
Wietse
> For completeness, I thought it might be helpful to still also answer your
> questions:
>
> - How is SPF integrated into Postfix? Hint: provide output from
> > "postconf -nf" and "postconf -Mf". See also
> > https://www.postfix.org/DEBUG_README.html#mail.
> >
>
> /etc/postfix-199/main.cf:
> policy-spf_time_limit = 3600s
> smtpd_recipient_restrictions =
> ...
> check_policy_service unix:private/policy-spf,
>
> /etc/postfix-199/master.cf:
> policy-spf unix - n n - - spawn
> user=nobody argv=/usr/libexec/postfix/policyd-spf
>
> - It's also good to know the output from "postconf mail_version",
> > and the OS version if you did not build postfix yourself.
> >
>
> postfix-3.8.5, fedora40 and pypolicyd-spf-3.0.4. I always include this info
> with every post at the top of my message.
>
> Thanks so much, as usual.
> _______________________________________________
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
