On Fri, Nov 25, 2011, Wietse Venema wrote:
> > > pkt-length command nreplies rcodes*nreplies null-terminated-rtext*nreplies
> Actually we can forget about the rcodes*nreplies part.
> The rcode isn't sent with SMFIR_REPLY, so it should not be sent
> with SMFIR_REPLIES either. With SMFIR_REPLY all three reply arguments
> are inside the rtext.
Yes, but the API allows to omit the text:
! int
! smfi_setreplies(SMFICTX *ctx, unsigned int nreplies, int *rcodes, const char
**rtexts)
! rcodes: a status array of size nreplies, each element must be one of
! SMFIS_TEMPFAIL, SMFIS_REJECT, SMFIS_ACCEPT
! rtexts: a text array of size nreplies, each element must be either
! NULL or a valid SMTP reply text which matches the corresponding rcode,
[1]
The existing API uses a return value for the xxfi_*() functions
plus a separate "custom reply" that can be set via smfi_setreply()[2],
while this function basically merges the two (reply code and reply
text). This allows the milter to just set a list of reply codes
without any custom text, which can make writing the milter code a
bit simpler (no need to allocate strings etc). Having both reply
code and reply text of course causes a consistency problem ("does
the code matches the text?"), but that should be already handled
for the existing API.
footnotes:
[1] to make things even simpler for a milter, rtexts could be NULL
too; it's not really required to created an array of NULLs.
[2] it might have been a better API to include an optional reply
text parameter for each xxfi_*() function.
