Handling mail aliases

Vernon Schryver vjs@calcite.rhyolite.com
Wed Jun 18 20:06:37 UTC 2003

> From: Spike Ilacqua <spike@indra.com>

> > It would be worse than ugly.  It's not just the SMOP (small matter of
> > programming), but the question of what dccm should do if a rejection
> > threshold is reached for one of the names for an alias but not all of
> > them.  Dccm can only tell sendmail to reject or accept for the
> > original name.
> I'd image the best thing to do would be to accept it for all in that
> case.  But yeah, it's ugly.

In the cases that really matter (e.g. when there really are several
recipients instead of several mailboxes owned by one person), that's
probably too ugly to use.  If you have to deal with the message
on a all-or-none basis for the alias, it seems to me you may as well
stick to the original alias.

> I bring it up because even though I have a very old, well published
> email address, the bulk of the spam I get is comming to role addresses,
> hostmaster, webmaster, etc.  There are certainly operational ways to
> handle the getting the logs checked and the whitelist maintained for a
> role address.  However if would be nice if it was part of peoples normal
> mail routine, just the way the mail to those aliases is, instead of
> outside of it.  If you've ever directed mail to a communal inbox a bunch
> of people we're *suppose* to check you know what I mean.

There are other tactics.  One might be to turn off filtering for the
alias (e.g. whitelist the address in the main whiteclnt file or the
alias's per-user whiteclnt file) and postpone filtering.  That might
be done during delivery with procmail (with or without dccproc) or
with another hop through an MTA (such as sendmail/milter/dccm).

Vernon Schryver    vjs@rhyolite.com

More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.