Claus Assmann:
> On Fri, Nov 25, 2011, Wietse Venema wrote:
> > Claus Assmann:
>
> > > #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
>
> > 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?
>
> Probably > 0, so we should add that flag.
>
> > What would you recommend for the (Sendmail Milter protocol) wire format?
>
> That's the ugly part I didn't want to think about yet... only after
> we come to some kind of agreement on the API.
>
> > 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.
That makes it:
pkt-length command nreplies null-terminated-rtext*nreplies
Where nreplies can be 32-bit. With the current 1M reply size limit,
sending 65536 replies would already be challenging, but numeric
limits are easy to change, whereas protocol field widths are not.
Otherwise, what you write sounds good to me. I agree we don't need
to introduce a new on-the-wire array encapsulation just to send an
array of RCPT TO replies.
Wietse
> I'm wondering whether there should be a length parameter for each
> null-terminated-rtext (to allow easy allocation of per-RCPT reply
> buffers plus validation of the packet) but that's not used elsewhere
> in the protocol, so we should go with your suggestion.
>
> #define SMFIR_REPLIES 'z' /* reply for PRDR */
> could be used for the command.
>
> > 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?
>
> It's applicable to all packets. However, _FFR_MDS_NEGOTIATE can be
> used to increase that size to 256K or even 1M.
>
> > Will there be a problem with local RCPT TO counts > the minimum 100?
>
> If the packet size is increased to 1M then it seems unlikely to run
> into that limit, but it certainly needs to be mentioned in the doc
> as a restriction.
