Two whitelist questions

On Monday 13 March 2006 07:08 pm, Vernon Schryver wrote:

> From: Andy Rudoff 

>>  ok env_to postmaster@myhost.com

>> what happens for bulk messages where the envelope recipient
>> list contains both postmaster@myhost.com and
>> anotheruser@myhost.com?

> If dccm determines that a message is spam for some recipients but
> not for others, it always delivers it to those recipients that want
> it. Because of limitations in the SMTP protocol, that generally
> means discarding the message for those recipients that do not want
> it.

I use a whiteclnt entry like the one above and it works fine: that is, 
dccm never rejects mail to postmaster but does not accept the message 
on behalf of other recipients.

> The SMTP protocol problem is that the receiving mail system must
> answer the DATA command with one of:
>   5yz reject--message unacceptable for all recepients
>   4yz temporarily reject--message currently unacceptable for all
>   but try again
>   250 ok--accepting message for delivery to all recipients

That's sort of an interesting conundrum that I'd never stopped to 
think about. I've seen that dccm does what it should (accept the 
message for whitelisted recipients and not for others) but I hadn't 
thought about how the available SMTP response codes constrain its 
options.

> I'm trying to figure out an option where will dccm temporarily
> reject (4yz) recipients in Rcpt_To commands with potentially
> differing decisions for the message (e.g. per-user whiteclnt files
> or greylisting) It's standard for an MTA to 4yz-reject Rcpt_To
> commands because the SMTP client has done too many, but I think RFC
> 2821 says the second Rcpt_To command is not supposed to be too
> many.

It actually seems somewhat clear on that point:

  The minimum total number of recipients that must be buffered is
  100 recipients.  Rejection of messages (for excessive recipients)
  with fewer than 100 RCPT commands is a violation of this
  specification.  The general principle that relaying SMTP servers
  MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation
  tests on message headers suggests that rejecting a message based
  on the total number of recipients shown in header fields is to be
  discouraged.  A server which imposes a limit on the number of
  recipients MUST behave in an orderly fashion,  such as to reject
  additional addresses over its limit rather than silently
  discarding addresses previously accepted.  A client that needs to
  deliver a message containing over 100 RCPT commands SHOULD be
  prepared to transmit in 100-recipient "chunks" if the server
  declines to accept more than 100 recipients in a single message.

So when faced with a message addressed to more than 100 recipients AND 
when running on an SMTP delivery server, it would be perfectly fine 
for DCC to greylist them all and let the SMTP client sort out what it 
should do about that (and what it should do is clear).

However, when running on a SMTP relay server, it must not reject the 
message (for any recipients) purely on the basis of "too many 
recipients" and this is what complicates things.

So your approach, if I understand it correctly, seems right on: 
deliver (or relay, as the case may be) the message to whitelisted 
recipients and greylist all others. With any luck, attempts to 
retransmit the message to those recipients that were temporarily 
rejected should arrive at the SMTP server in smaller batches, so if 
all goes well, the process should bottom out eventually.

"All goes well" here means that the SMTP client behaves as it should, 
though, and it's hard to know whether you can count on that or not.

--