Courier and DCC

Vincent Schonau
Thu Apr 11 22:51:23 UTC 2002

On Wed, Apr 10, 2002 at 11:37:35AM -0600, Vernon Schryver wrote:
>> From: Vincent Schonau <>
>>>> 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 "[45]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 :)

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.



More information about the DCC mailing list

Contact by mail or use the form.