mailmary--- via Postfix-users:
>
> Hello everyone,
>
> I'm coding a milter and I noticed an issue with postfix. Once postfix is done
> communicating with the milters, instead of sending a SMFIC_QUIT, it sends
> SMFIC_ABORT.
>
> abort all milters
> milter8_abort: abort milter inet:127.0.0.1:8891
> milter8_abort: abort milter inet:127.0.0.1:8893
> milter8_abort: abort milter unix:/run/spamass-milter/postfix/sock
>
> Is this the correct thing to do? Because based on the documentation, the
> SMFIC_ABORT keeps the connection open and keeps on listening for more data:
>
> > Abort current filter checks. Resets internal state of milter program
> to before SMFIC_HELO, but keeps the connection open.
>
> Any help would be appreciated.
What you see is Postfix SMTP server sending SMFIC_ABORT when it
resets internal state. If the Postfix SMTP server expects no more
SMTP commands, then it disconnects from the milters without sending
SMFIC_QUIT.
If that behavior causes your code to "leak" file, memory, or other
resources, then that is a basic robustness problem in your code
that you need to address there.
Just like there can be no guarantee that an SMTP client will "finish"
an SMTP conversation with QUIT before discinnecting, there can be
no guarantee that an SMTP server will "finish" a Milter conversation
with SMFIC_QUIT before discinnecting.
A robust program expects that networks will sometimes break and
that clients ane servers will sometimes crash, without leaking file,
memory, or other resources.
The Postfix code has worked since 2006 without causing errors in
every milter that has been thrown at it. Adding a milter_disc_event()
call to send SMFIC_QUIT would just add another protocol round-trip
without any real benefit.
Wietse
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
