white list and mailing lists (eg. Yahoo groups)

> From: Levent Serinol <lserinol@yahoo.com>

> > Another problem with "OK" whitelisting by IP address
> > is that it
> > white-lists all mail from the source.  Yahoo
> > "groups" mailing lists
> > have been abused in the past.
>
>  This part really needs take care of bunch of IP
> addresses. It does not look flexible to me.
> ASAP, DCC does not handle regexp.Therefore, writing
> *.yahoogroups.com as a whitelist entry doesn't work.

I do not understand that comment.  By the nature of things,
a checksum system like the DCC cannot handle regular expressions.

If you want to whitelist all of *.yahoogroups.com for all of your
users despite the history of complaints about unsolicited bulk mail,
it should not be hard to find all of the IP addresses from which they
send and white list them.  I doubt Yahoo sends their mail from more
than a few dozen IP addresses.

However, that tactic won't solve the mailing list problem except
for small domains using the DCC and for mailing lists maintained by
organizations you consider reliable.  If you have many users, they
will continually sign up and un-sign-up to mailing lists, and not just
from Yahoogroups.


> ...
> > That example would white-list only mail that both
> > comes from the SMTP
> > client at 10.1.2.2 and carries the envelope
> > Mail_From value list@domain.com
>
> It does not seem to me possible,'cause our users's are
> susbcribed to many groups on yahoo and other sites.
> and they keep on subscibing to new groups oftenly.
>
> Do you have any other idea about solving this problem

One obvious idea is to build a mechanism that your users could use to
add to a system-wide whitelist.  It would be easy to write a CGI script
that let any of your users append to a system-wide DCC white list.

Another idea is to give each user a DCC white list file maintained
with a web page.  It would be easy to write a CGI script that lets
a user maintain a private DCC whitelist.  Then you could use
`dccproc ... -w user-whitelist` inside a sendmail .forward script or a
procmail recipe.


> P.S. Have you got my mail about dcc+qmail integration
> ? I sent you it twice, but got no answer back.

I couldn't figure out how to answer.

I don't understand qmail, but you as well as others seem to have said
that it wants a filter that is started with fork()/exec() for each
recipient of each message.  If that is true, then I don't see a lot
that needs to be done.  Besides a more convenient way to pass the
envelope, headers, and body, what is needed?  Is that needed?

I am unlikely to spend the time required to understand the internals
of qmail enough to design a DCC interface optimized to qmail for a
bunch of reasons.  I have prejudices against qmail that are based on
characteristics of qmail (e.g. its free and easy stretching of the
STMP standard) as well as on things that have nothing to do with the
qmail code itself, but there are larger concerns.  One is that I should
first spend on other projects that would be used by more people, such
as something for Comminigate or a WIN32 DCC client.

If you have explicit suggestions for changes to dccproc or a new DCC
client program, I'd be glad to hear them, and might write something.
If you have reasonable complete code, I'd be happy to start to look
at it, but I cannot promise to do more.
Because the DCC source carries a BSD style license, you can improve
it as much or as little as you wish and distribute it as you wish.
Permissions, licenses, and my prejudices permitting, I do ship code
written by other people (not so far in the DCC), but I have a lot of
very picky prejudices about how code should look and work.


Vernon Schryver    vjs@rhyolite.com