Wietse Venema:
> - 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
The specification does NOT state that after STARTTLS the MTA must send an
SMFIC_ABORT.
It only states that when SMFIC_ABORT is sent, between emails with the same
connection, to reset everything except the connection information (since its
the same I guess?)
At least that is how I interpret
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
(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
mailmary--- via Postfix-users:
>
> Hello everyone,
>
> While running my milter, I noticed an inconsistency filtering incoming mail
> by their connection information and by inconsistency I mean complete lack of
> data. Of course it could be a bug in my milter, but in case it is not, here
> is
Hello everyone,
While running my milter, I noticed an inconsistency filtering incoming mail by
their connection information and by inconsistency I mean complete lack of data.
Of course it could be a bug in my milter, but in case it is not, here is the
problem:
A normal (unencrypted)
