dccifd spam reporting and env_to whitelisting

Vernon Schryver vjs@calcite.rhyolite.com
Fri Jan 23 22:39:05 UTC 2004

> From: chris@mikk.net

> >         ...  First your your system somehow decides that a message is
> > spam and seeks to report it as certainly bulky to the DCC.  Then your
> > system wants to consult dccifd to see about delivering the message.
> > What if you separate those two tasks into two different interactions
> > with the DCC?
> The following sequence could happen:
>  	1) message is reported as spam to DCC server #1
>         2) client switches to DCC server #2
> 	3) message is queried against DCC server #2,
> 	   and accepted for all recipients.
>         4) checksum is flooded from server #1 to server #2
> Although it's not the end of the world, it is unreliable,

Can you quantify how unreliable it is?  How does that number
compare with the probability of other failure modes?

Note that DCC clients don't switch servers capriciously.  As
the interval between #1 and #3 decreases, #2 becomes less likely.
As that interval increase, #4 is more likely to happen before #3.

> and not a very clean solution (you waste a query to the
> DCC server just to consult the dccifd whiteclnt and
> userdirs).  If dccifd treated bulk mail the same whether
> it gets the "bulkiness" from the MTA or the DCC server,
> I could cleanly and reliably do this with one query.
> ...

Cleanliness is a characteristic of an entire system.  Adding
rarely used features produces systems like those from Redmond.

If this situation is frequent enough to matter, why do you want to not
filter spam to postmaster and abuse?  How frequently is legitimate
sent to both postmaster and some other address and is a false positive
for whatever you use to detect spam and turn on DCCIF_OPT_ISSPAM?
Wouldn't it be better to fix your spam detector to have fewer 
false positives?

Vernon Schryver    vjs@rhyolite.com

More information about the DCC mailing list

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