Using DCC with forwarding?

Vernon Schryver
Mon May 20 05:01:31 UTC 2002

> From: Gary Mills <mills@cc.UManitoba.CA>

> ...
> I'd better give an example:  When mail for `'
> arrives at our main mail server, sendmail maps that virtual alias to
> `'.  This is a local address, so it's delivered
> locally.  However, when mail for `' arrives,
> the alias is mapped to `'.  This mail is relayed
> to the staff mail server, and delivered there.
> There are thousands of those virtual aliases.  The database is rebuilt
> every night.  


>               According to the new-style DCC log files, sendmail has
> resolved the aliases by the time it connects to dccm.  I can see from
> there which are local and which are not.  

Are you sure of that?  You seem to be running 8.12.3 as I am, but in
my fiddling with things, I don't see the aliases resolved.  Addresses
are and must be resolved for sendmail to tolerate the Rcpt_To command
even before Milter filters are called, but I don't know how a Milter
filter can get the alias.

>                                           I don't want to build a
> whitelist when sendmail already has the information.  I had hoped that
> there was a nicer way to discriminate between local and relayed mail.

Besides that problem of discriminating, there's the problem of
double-counting.  Unless you white-list the IP addresses of your two
SMTP servers, mail that is forwarded from one to another will be
reported to DCC servers twice and so have its counts doubled.  If you
do white-list the SMTP servers's IP addresses, the second server won't
reject anything.

A third problem is that if the second SMTP server did reject, you'll
be double-bouncing any spam with bogus return addresses into your
postmaster mailboxes.  That's likely to be a lot.

Thus, it would be very much better if you could somehow reject at
the first sendmail+dccm that sees the message.

> > I suspect it would be easier and cleaner to move all of the logs to one
> > system.  One obvious way is an rdist cron job.  Perhaps a better way
> > would be to have only one real set of log directories on one of the
> > two machines and to NFS mount them on the other machine.
> There are different user names on each system.  Combining them
> wouldn't help.  I want to get the right log files on the right system.

Well, if you don't like the thought of lots of rdist's, how about
lots of symbolic links over NFS?  For example, have 
/var/dcc/userdirs/local/big_cheese on one system be a symbolic link
to /othersystem/var/dcc/userdirs/local/bcheese
Your mechanism that rebuilds your database every night could also
delete and recreate the symbolic links.

> ...
> This is certainly a problem.  In our case, with about 30 000 accounts,
> we wouldn't want separate passwords for this function.  I'll probably
> use an apache module that authenticates via PAM.  The CGI script would
> have the responsibility for displaying only the user's data.  As I said,
> I haven't put these pieces together yet.
> > Am I wasting my time working on such spam scripts?  I suspect as much,
> > because I suspect anyone who might use them has already solved the
> > web-access-to-user-files problem.
> If it's solved, I haven't heard about it.  Both of our mail servers
> are `sealed servers', running Cyrus IMAP.  Users have no direct access
> to them.  Much as I'd like to, I can't move DCC out of logging-only mode
> until users have a way to see what DCC is doing.  A web page seems to
> be the way to do it.

I'm thinking of a sample that would 
  - create authentication with htpasswd
  - a generate per-directory .htaccess file with the required
      "require user" line, because I've not figured out how, if there
       is a way say "this directory requires a user name that is the
       last component of the pathname."  It seems like an obvious
       need, but I don't see anything that does that in Apache 1.3.
  - a CGI script to manipulate the whiteclnt file.
  - ordinary Apache directory listing for the log directory.
No frames.  No pictures or logos.  Just something that works and that
could be rewritten to fit local requirements.

Vernon Schryver

More information about the DCC mailing list

Contact by mail or use the form.