Claus Assmann:
> [resending with correct From: address]
> On Wed, Nov 23, 2011, Wietse Venema wrote:
>
> > - Milter-based filters would use an extended Milter protocol and
> > libmilter API to send per-recipient end-of-data replies.
>
> > The Milter protocol extension would involve new elements something
> > like SMFIF_PRDR (a feature flag to announce the capability) and
>
> This:
> #define SMFIP_PRDR 0x00200000L /* MTA supports PRDR */
> isn't really necessary as the milter must parse the MAIL arguments
> anyway to determine whether the client uses PRDR. If the MTA doesn't
> support it, it doesn't send the MAIL command with a PRDR argument
> to the milter anyway because it rejects that as unknown parameter.
> Hence I'm not sure whether it's worth "wasting" a bit on it.
What are the odds that an MTA passes MAIL FROM..PRDR to the Milter,
yet is unwilling to receive the new multi-reply response from the
Milter?
> > SMFIR_PRDR (one reply per recipient, each formatted as with
> > SMFIR_REPLYCODE). If we can freeze the details, then it could be
> > in Postfix 2.9, which is due early 2012.
>
> Suggested API for replies (based on the MeTA1 API):
>
> int
> smfi_setreplies(SMFICTX *ctx, unsigned int nreplies, int *rcodes, const char
> **rtexts)
>
>
> where
>
> nreplies: number of replies, this must match the number of valid
> RCPTs for the transaction.
>
> 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,
> i.e.,
>
> SMFIS_TEMPFAIL 4xy
> SMFIS_REJECT 5xy
> SMFIS_ACCEPT 250
>
> including enhanced status code and a textual description, ending
> in \r\n. The text must be formatted as described in the SMTP RFCs,
> i.e., 821/2821/5321.
What would you recommend for the (Sendmail Milter protocol) wire format?
pkt-length command nreplies rcodes*nreplies null-terminated-rtext*nreplies
All this would have to fit in the max packet length which is 65535
if I recall correctly, or is that applicable only for body chunks?
Will there be a problem with local RCPT TO counts > the minimum 100?
Postfix currently has no explicit upper limit, i.e. INT_MAX. The PRDR draft
cites RFC2821 without excluding multi-line replies.
Wietse
