mailmary--- via Postfix-users:
>
> (resending because the previous email failed to submit due to its size)
>
> I'm sorry I did not provide enough information.
>
> With "the next email" I mean the next SMTP SESSION, a different sender.
>
> I should also mention that I'm using AlmaLinux (derivative of RHEL) which
> comes with the following postfix version: postfix-3.5.8-4.el8.x86_64
>
> Please find attached two debug logs, one from my milter and one
> from postfix (running with smtpd -v). The logs have been created
> in my local environment, a Fedora server sending a single email
> to an Alma server.
If the question is about missing 'CONNECT' macros after STARTTLS,
then that is easily explained.
- After the remote SMTP client connects to Postfix, The Postfix
SMTP daemon sends 'CONNECT' macros (j, _, {daemon_name}) and
SMFIC_CONNECT.
- After the remote SMTP client sends STARTTLS, the Postfix SMTP
daemon sends SMFIC_ABORT to reset Milter state to the state before
HELO/EHLO.
Quote from milter-protol.txt:
'A' SMFIC_ABORT Abort current filter checks
Expected response: NONE
(Resets internal state of milter program to before SMFIC_HELO,
but keeps the connection open.)
- Most notably, the Postfix SMTP daemon will NOT send SMFIC_CONNECT,
and will not send the associated 'CONNECT' macros.
So the question becomes:
- Should Postfix send SMFIC_CONNECT (and 'CONNECT' macros) after
the server sends SMFIC_ABORT? That seems inconsistent with
milter-protol.txt, which says that SMFIC_ABORT resets the milter
state to before HELO, not before CONNECT.
- Should the Milter after SMFIC_ABORT remember the info that it
received with SMFIC_CONNECT? That would be consistent with
milter-protol.txt.
Now, milter-protol.txt was written after-the-fact, by looking at
the Sendmail implementation. It was not the authoritative spec from
which Sendmail was implemented.
Wietse
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
