Thu Apr 11 22:51:23 UTC 2002
On Wed, Apr 10, 2002 at 11:37:35AM -0600, Vernon Schryver wrote: >> From: Vincent Schonau <email@example.com> > >>>> There are actually two phases to filtering: rcptfilters are called >>>> after you have the HELO/MAIL FROM/RCPT TO, and you can give "thumbs >>>> up", "thumbs down", or "maybe" at this point. >> >>> How do they handle multiple RCPT_TO values? >> When a recipients mailfilters reject the message, an appropriate 5xx >> response is issued during the SMTP conversation. If some recipients want >> to accept, but others don't, and the sending SMTP client continues after >> this 5xx error (with DATA), the mail will be delivered to the address >> who had accepted the message, but not to those that hadn't. > What about individual recipients who decide they don't want the message > at the end of the DATA command? That's the situation with the DCC. > It is not until the end of the DATA command that recipients know that > they don't want a message because it is bulk and something about the > message (e.g. the sender) is not whitelisted. I've not had the time to test this fully yet, but so far, I _think_ I've seen bounces referring to the address that denied the message, generated by the sending MTA. > My tactic with dccm+sendmail when there are both willing and unwilling > recipients is to use the sendmail milter interface to tell sendmail to > remove those who don't want to receive the message from the addressee > list. That has the disadvantage of not generating a bounce for those > addresses that refused the message, but it does deliver it to those who > want it. The underlying problem is that the SMTP server can only say "2yz > good message for all recipients" or "yz bad message for all recipeints" > in response to the DATA command. (I wouldn't count on a 4yz response > to the DATA command working with all SMTP clients.) I'll test this more extensively when I have some time, and will try to log some conversations. In the meantime, those interested should feel free to browse the courierfilter and localmailfilter manpages linked off http://www.courier-mta.org/ :) My tolerance for clients apparently unable to cope with the relevant standards is dropping rapidly, so I guess I'll find out when I move to production. I can allways whitelist. >> This seems appropriate; it works with my installations. I'm not quite >> sure how mailservers other than qmail respond to seeing 5xx during the >> SMTP-conversation, especially before DATA. > Historically, 5yz answers to DATA have been the problem. > For example, Hotmail long ignore 5yz responses to the DATA command, > and now, leaks potentially private information from other transactions. Yes, I've seen mention of that. >> There's a blurb in the localmailfilter documentation that refers to >> 'users being unsubscribed from mailing lists due to other users poorly >> written filters'. > No reasonable SMTP would be confused by a 5yz response to one Rcpt_To > command. I think that refers to bounces generated under strange circumstances. See my comment about standards above. > There are words in RFC 2821 about 5yz and 4yz responses to individual > Rcpt_To commands. >>>> The one thing I didn't see was the HELO value! >> The HELO value is reproduced as >> >> Received: from <helo-value> >> >> in the top Received: header, available to smtpfilter. > That seems a little late for filters other than the DCC, because > most of them want to filter before the DATA command and so before > any of the headers have been received and so before a Received header > can be added. > For filters like the DCC that don't do regular expressions, it is > not helpful. Agreed. In most Courier+DCC scenario's so far, however, the DCC would be implemented either using a wrapper program or in a maildrop filter that (could) have those facilities. I imagine filtering on HELO value will be built into Courier natively sooner or later. Regards, Vince.
More information about the DCC