> From: Gary Mills
> We have thousands of users. The most common e-mail from Ebay/Paypal
> is for new passwords or password changes. These get rejected as bulk
> mail, which is confusing to our users.
If the DCC FUZ2 checksums of those messages are the same,
then you could add a line like
ok hex fuz2 xxxxxxxx yyyyyyyy zzzzzzzz wwwwwwww
to /var/dcc/whiteclnt to whitelist them.
Or talk John L into adding the lines to his list at
http://www.iecc.com/dcc-testmsg-whitelist.txt
Then use the cron job /var/dcc/libexec/fetch-testmsg-whitelist to
regularly fetch his list, and add
include testmsg-whitelist
to /var/dcc/whiteclnt to whitelist everything in the list.
> The only available source appears to be for dkim-milter. I'm about to
> build this for sendmail-8.14.1. I don't mind running another milter,
> in addition to dccm. In fact, dkim-milter should be fairly
> lightweight. It would have to run before dccm so that it could set
> macros, create headers, or something, that could be noticed by dccm.
If you
- use a fairly recent version of sendmail so that the order you
specify milters affects the order in which they are applied,
- dkim-milter runs before dccm,
- dkim-milter sets the sendmail macro ${dcc_isspam} to something
useful as described in the dccm man page, and doesn't tell sendmail
to do anything about mail,
- you add the line following line descrived in the dcc man page to
/var/dcc/whiteclnt
option -first
then you would have partial per-user control of dkim-milter. It would
be only partial because users could only whitelist senders that might
otherwise be blocked by dkim-milter.
I do not know whether macros set by one milter are seen by others.
> > DCC client code of several versions ago had hooks for third party
> > mechanisms.
> Are these necessary if the external code is another milter? The part
> that I really need is the user control of rejection. I don't want two
> different mechanisms, one for DCC-determined bulk mail, and another
> for DKIM verification.
That code included understanding lines in whiteclnt files like
option xfilter-on
and
option xfilter-off
so that individual users could choose to apply the third party mechanism
or not.
I guess it would not be too much work to add support for another
sendmail macro and a whiteclnt switch for paying attention to it.
However, none of this would do anything for dccifd or dccproc.
Another tactic might work better. If headers added by a sendmail milter
are seen by later milters, and if dkim-milter always deleted, replaced,
or added a X-dkim-milter:good, X-dkim-milter:bad, etc header, then dccm
could be controlled by individual whiteclnt file lines that white- or
blacklist based on X-dkim-milter headers. A simple SMTP proxy that could
be used as a Postfix before-queue filter could be used with postfix+dccifd
and perhaps other MTAs.
The big question for me is whether later sendmail milters see earlier
milters' added or changed headers. I think not, but I don't know,
and I'm too lazy try to read the code or write a test milter.
Vernon Schryver [EMAIL PROTECTED]
_______________________________________________
DCC mailing list [email protected]
http://www.rhyolite.com/mailman/listinfo/dcc
