More headers for whitelisting?

On Mon, Jul 16, 2001 at 08:58:13AM -0600, Vernon Schryver wrote:
> 
> If the SMTP client's IP address is reliably represented in a 
> header added by the last MTA, then it could be picked
> out and given to dccproc with as the value of -a.

Hmmmm.  Maybe I will cobble up some procmail to yank it out of the
Received: header that my MTA adds.

> RFC 2821 says that Return-Path should contain the value of the envelope
> Mail_From command.

Indeed.

> I will make the next version of dccproc optionally
> (or maybe by default?) use the value of a Return-Path header instead
> of -f (or maybe when -f is absent?).

In absense of -f sounds good.

> I can't see a compelling use for the value of sender header, because
> according to section 3.6.2 of RFC 2822, it is approximately the same
> as the header From value.  Personally, I'd not whitelist except on
> values that are unlikely to be forged, including the envelope Rcpt_To
> value and the IP address of the SMTP client.

Indeed, and I agree.  But in dccproc (which is less than optimal
itself) those are not available.  The Sender is forgable yes, but it
is also pretty reliable for whitelisting mailing lists.

> The checksum types used by dccproc for whitelisting use the same
> very precious namespace as checksum types in the on-the-wire protocol.
> That space is precious because it is tiny (I think 4 bits) to keep
> the database used by the DCC server small.  That matters if you want
> to allow a single database to have checksums for a noticable fraction
> of the mail messages in the Internet.  

I don't think I was thinking about checksumming them, just using them
to tell dccproc not to checksum/database file/lookup the e-mail.

> Given the environment in which dccproc is used, this should not be a
> problem.  It should be possible to use familiar tools to avoid asking
> dccproc about messages with stigmata that dccproc doesn't notice.

I supposed I could whitelist mailing lists in procmail itself.  I was
just hoping to do it with DCC itself so that porting to the SMTP
initiated DCC would be painless.

b.