dccm core

Vernon Schryver vjs@calcite.rhyolite.com
Wed Jul 21 16:45:36 UTC 2004


> From: "Bolmerg-Berliner Ludger - Munich-MR" 

> I am getting a core (signal 11, Segmentation fault) when starting dccm 1.2.50 on FreeBSD 5.2.1 with sendmail 8.12.11

> #0  0x0804d5f3 in log_write ()
> #1  0x0804c5bc in set_reply (wp=0x80e7694) at dccm.c:1265
> #2  0x0804cc7e in dccm_eom (milter_ctx=0x80e794e) at dccm.c:1510

> Jul 21 12:03:44 netserv dccm[32266]: smfi_setreply("","","(null)")=-1


That seems similar sounding problem to observed by Krzysztof Snopek.
It would be good to know if this new crash is fixed by the same patch:


*** old-dccm.c  Sun Jul 11 18:01:04 2004
--- dccm.c      Sun Jul 11 18:01:07 2004
*************** set_reply(WORK *wp)
*** 1250,1255 ****
--- 1250,1259 ----
  {
        int i;

+       /* temporize if we have not figured out what to tell sendmail */
+       if (!wp->reply_ptr)
+               make_reply(wp, &temp_reply);
+
        i = smfi_setreply(wp->milter_ctx,
                          wp->reply.rcode, wp->reply.xcode, wp->reply_ptr);
        if (i != MI_SUCCESS)


*** xxxxxx

I've not released a 1.2.51 with that change because I'm fiddling
with a change to greylisting.  The idea is to stop embargoing all
messages from an IP address as soon as one message or one greylist
triple of (sender,target,IP address) has been accepted.  A example
of where this feature might be useful is this mailing list.  Messages
from new subscribers are first greylist embargoed when sent to the
service address, and then again when sent to the submission address.
Then there are service providers with many SMTP clients.

I have two problems in addition to the obvious doubt about whether the 
basic idea is wise:

  1. interactions with dccm and dccifd -G IPmask/xx
   For example, when using `dccm -G IPmask/24` and a message from
   10.2.3.4 has been accepted, should the new feature stop embargoes
   for 10.2.3.5 as well as 10.2.3.4 or only for 10.2.3.4?  One of
   the side effects on releasing 10.2.3.5 would be on server-side
   whitelisting.  If you use IPmask/24, do you whitelist 10.2.3.4
   or 10.2.3.0/24 in /var/dcc/grey_whitelist?  Note again: that is
   only server-side whitelist entries for greylisting.


  2. greylist server/client compatibility
   The greylist clients must send the IP address to the greylist
   server in two new cases.  That requires a change in the protocol.
   The DCC/UDP/IP packets include DCC protocol version numbers so
   I could add a bunch of code to DTRT (do the right thing) with
   mismatched greylist servers and clients.  However, such code is
   always nasty, ugly, hard to get right, and a wart forever.  I
   think most DCC greylisting installations have closely coupled
   clients and servers, so no one would notice if veresion 1.2.51
   of dccd is incompatible with version 1.2.50 of dccifd or dccm
   or vice versa.  Am I wrong about that?

   Note again: this proposed incompatibility only concerns greylisting.
   Ordinary DCC clients and servers must remain compatible regardless
   of warts.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

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