greylisting for tagging purposes (and queries)

Vernon Schryver
Sat Apr 8 16:38:01 UTC 2006

> From: john crawford 

> I am testing the greylist functionality. I'm initially considering
> using dcc to delay grey inbound messages (no rejection or discard, but
> tagging for bulk and dnsbl is desired).

What do you mean by delaying but not rejecting or discarding?  The
usual notion of greylisting is to delay mail with temporary rejections.
In principle one might slow responses to SMTP commands if the
combination of STMP client IP address, envelope Mail_From value,
and one of the envelope Rcpt_To values is unfamiliar, but dccm and
and dccifd have no provisions for that.

Ordinary greylisting must be done during the SMTP transaction.  After
message has been accepted is too late.  That implies that many installations
using dccifd cannot use greylisting.  For example, if you use SpamAssassin
to talk to dccifd, then you would need to using something like one of
the SpamAssassin sendmail milters.  I suspect you would also need to
teach SpamAssassin to recognize the 'G' result from dccifd.

Postfix could greylist with dccifd as a before-queue filter, but I think
Postfix has other available greylisting mechanisms.

> I'm working with dccifd options and dcc_conf settings and not getting
> dnsbl feedback on the headers. I'd like tag DCC/DNSBL results once the
> embargo ends. If I get a MANY or DNSBL match the message enters
> immediately. I'd kind of rather have it retry longer but maybe I have
> to live with that. I do get MANY condition (rej-thold) header tagging
> which is good, but I've not seen any dnsbl information at all on a tag
> header when dnsbl does match (as shown in the log).  How can I get a
> dnsbl report into the headers?  (dccifd returns result A, oks R).
> I'll append my current dccipd options and dcc_conf settings and a log
> tail below.

I don't understand some of that (e.g. "result A, oks R").

It might be better to use "-B,any" to override the
default target DNS value of  Spamhaus encodes things in their
DNS values.   See

Because there are false positives with most DNS blacklists (e.g. what
if you are the ISP for a spammer and want to receive its private,
non-spam mail?), DNSBL results are ignored by dccifd and dccm unless
the following line appears in a per-user whiteclnt fire or

option DNSBL-on

I suspect that line is absent and is one of the reasons why your
DNSBL hits are being ignored.  Another sufficient reason is telling
dccifd "no-reject".  That's what this line means in your log file:

result: ignore and accept

Dccproc assumes "option DNSBL-on" because dccproc is always (in
my model) invoked for a single mailbox, and there's no reason to 
say "yes, I really meant to use `dccproc -B`".

> the ip in the analyzed receive line. I know I can specify rcvd-nxt for
> a specific offset,

rcvd-nxt for dccifd and `dccproc -r` was the first idea to deal with
finding the IP address of mail senders.  They are still supported for
upward compatibility reasons, but I should have removed their references
in the man pages.  MX and MXDCC in the whiteclnt file is the better idea.
See their discussion in `man dcc`.

>   ... The delay gives me a hypothetical chance to have the embargoed
> messages flag dirty via rbl, bulk or updated virus scan. I have
> implemented this logic, adding the flexibility to force feed to dcc
> the correct ip address of the foreign-handoffipserver, within an
> external header analysis program and passing the parsed ip address to
> dccifd but I'm wondering if I'm missing a feature within dcc's logic
> for this.

I don't understand at least part of that.  In any case, if the issue
is how to get dccifd to skip Received: headers added by locally
administrated MX servers, please consider MX or MXDCC lines in the
whiteclnt file.

A definitive black- (e.g. DNSBL) or whitelisting (e.g. whiteclnt) result
turns off greylisting for a message.  More than that, a blacklisting
result deletes information for the IP address from the greylisting
database and so resets embargoes for that sender.

> As a matter of curiosity, if I turn off the query flag and use
> greylisting, when does the dcc logic return the metrics to the queried
> server for the message being analyzed? How does it increment the "I've
> seen this" counter? It shouldn't increment by one for each time the
> greylisted message is retried (reseen). Does it increment the first
> time it sees that fingerprint and not increment for similar
> fingerprints in the near future? Thanks.

Yes, the embargo # seen in log files is used by the DCC client to convert
what would otherwise be a report to the DCC server into a query.

> an example log where dnsbl matches but doesn't appear as a header/tag
> (and doesn't embargo) is at the very end.

In that case, the DCC client does not ask the greylist server anything.
Instead it tells the greylist server "This is a bad guy.  Purge your
records for it."  It also reports a count of "MANY" to the DCC server.

Vernon Schryver

More information about the DCC mailing list

Contact by mail or use the form.