More headers for whitelisting?

> From: "Brian J. Murrell" <dcc-list@interlinx.bc.ca>

> I am doing dccproc for the time being.  Of course by the time an
> e-mail makes it to a point where dccproc can use it (i.e. procmail or
> other local delivery means) one loses all the envlope information,
> save for "Return-Path:" and/or "Delivered-To:" headers if one's MTA is
> so gracious.
> 
> I am wondering if it would not be useful in whitelisting (at least) to
> at least recognize locally more headers.  Personally, I would ideally
> like to see Return-Path: and Sender: matching for whitelisting
> purposes.
> ...

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.

RFC 2821 says that Return-Path should contain the value of the envelope
Mail_From command.  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?).

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.

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.  

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.


Vernon Schryver    vjs@rhyolite.com