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 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.
