mailmary--- via Postfix-users:
>
> we must be looking at different manuals/specifications because I
> don't see how a SMFIC_ABORT is implied here.
Your SMFIC_ABORT implementation of this spec:
Quote from milter-protol.txt:
'A' SMFIC_ABORT Abort current filter checks
we must be looking at different manuals/specifications because I don't see how
a SMFIC_ABORT is implied here.
but
I don't think it matters anyway, it should not make any difference, just extra
traffic between postfix and the milters :)
I'll adjust my milter to expect SMFIC_ABORT after STARTT
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 b
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 (derivati
(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 pos
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 t
