greylisting for tagging purposes (and queries)

john crawford
Sun Apr 9 01:44:13 UTC 2006

At 12:38 PM 4/8/2006, Vernon Schryver wrote:
> > 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?

I mean temporary rejection, sorry, to return 4xx
not 5xx  to the sending smtp server for things
not whitelisted or otherwise accepted. I'm not tarpitting.

>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.

I'm still within the smtp transaction and could reject/permanent if
I wanted that functionality.

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

I'm actually running qmail and doing header tagging during
the smtp connection using qmail-qfilter routines. Currently
I tag for dcc bulk, razor, and an assortment of rbl's based
on the ip address of the injecting (off-campus) smtp server.
Now I'm playing with dcc greylisting with dccifd and
seeing what I can get from your uniform resource identifier
(no-envelope) filtering logic in the way of tags.

> > 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").

I mean "A" first character line of overall result advising the mta to accept
the message for all recipients and answer the SMTP DATA command with 
a 2yz result.

and second response of R for rejection for the single corresponding recipient.
Since I'm doing no reject I guess it doesn't actually take the R action.

The key point is that I don't have the dnsbl (for no-envelope in this case)
matched information put into a header tag.

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

Okay, that's helpful, I'll probably really use
some combination of and
settings since I'm interested here in
the uri filtering using no-envelope.

>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

Is there a combination that allows me to receive the
message, yet have the dbsbl match included as a tag
in the headers? If I take no-reject out can I have
the message come through to the recipient(s) marked?
That's really what I'm going for her, and if I get
temporary rejection for greylist embargo, so much the better.

If I can't get no-envelope SURBL - Spam URI Realtime Blocklists (rhsbl)
information on the header after an accept, then I'll just move that 
out of the dcc realm.

>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`.

I think I need to test this more. In my mind it was whitelisting mail
through these servers, not skipping to read deeper into the Received: chain.
We have central campus server forwarding to the department level (depending
on address used) so I'm ultimately hoping to have dcc figure out the
off-campus pass-off server ip address for ip scrutiny/testing.
I'll test some more and see if I can get that to work.

> >   ... 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.

Okay. Fine, thanks. Now I just hope find a way to have a header tag
or otherwise be able to incorporate analysis logic so that I can
know when dnsbl plays a part in the per-user "R" rejection
when I want to tag (not reject or discard).

> > 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.

Okay. Thanks. Makes sense. If on a subsequent embargo retry
the message trips positive for an rbl lookup, does the MANY
report occur?

> > 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.

Thanks so much for your help.

>Vernon Schryver
>DCC mailing list

More information about the DCC mailing list

Contact by mail or use the form.