On Wed, Nov 23, 2011, Viktor Dukhovni wrote: > On Tue, Nov 22, 2011 at 08:30:49PM -0500, Wietse Venema wrote:
> > I just stubled across this thread: > > http://www.gossamer-threads.com/lists/exim/users/90005 > > We could take a bold step and do it in two "main stream" MTAs, > > damn the torpedoes. > Is it worth the effort? Will enough SMTP clients whose messages I don't know -- I implemented it because I like the feature and I was a bit involved in the discussion on the PRDR draft. > one may be inclined to partly reject actually support this extension? Well, the MTAs that support it will hopefully do it both as client and as server. > If not, what do we gain by only being able to apply per-recipient > content-dependent policy to a small fraction of the traffic from > largely legitimate MTAs? The current way some filters implement per RCPT filtering is done by applying the filter to the first RCPT and every RCPT that doesn't have the same filtering configured will be temp-failed, hence there is extra load (queueing, retrying) on the client to send those RCPTs again. This could be considered an incentive to implement the feature on the client side. > When would Postfix reply negatively for recipient "A" and positively > for recipient "B" after DOT? How would this be exposed to existing Per RCPT filtering is a feature that is often asked by ISPs who offer anti-spam/virus for their customers: some pay for additional filtering. > proxy filters and milters? I've extended the (p)milter API (quote from the MeTA1 doc): ------------------------------------------------------------ To set reply codes for commands that need multiple reply values the function: sm_ret_T sm_pmfi_setreplies(pmse_ctx_P pmse_ctx, uint nreplies, int *rcodes, const char **rtexts) must be used. Currently this function makes only sense if PRDR is available in the SMTP server and actually used by the client. A pmilter can determine the latter by parsing the arguments of the MAIL command (see pmfi_mail()). Note: currently the argument rtexts is ignored, only the array of reply codes (rcodes) is used. The size of this array must be nreplies which must match the number of valid RCPTs for this transaction. The reply codes in that array must be in the same order in which the RCPTs have been received. ------------------------------------------------------------ Something similar could be added to milter.
