segmentation fault in dccproc (1.3.24)

Vernon Schryver
Sun Dec 11 01:30:58 UTC 2005

> From: Jeff Mincy 

> > What generated the bogus Return-Path header?  Of course dccproc should
> > not crash, but neither should whatever it was generate bogus headers.
> The bogus Return-Path header came directly from a spam message.  The
> spam message was not trying very hard to evade filters, so I'd guess
> that the originator of the spam message was misconfigured.  I (briefly)
> thought about adding a procmail/formail rule to rewrite the bogus header as
> coming from a special '' domain, but he problem doesn't
> happen often enough (much less than 1% of spam messages this kind of broken
> return-path header).

Page 50 of RFC 2822 says that the Return-Path "MUST" be added by the final
MTA.  Page 51 then says

   SMTP servers making final delivery MAY remove Return-path headers
   before adding their own.

Thus, Return-Path ought to be as reliable as the last Received header.
A quick test suggests that a largely default-configured 8.13.4 sendmail
removes an existing Return-Path header before delivering.

So which MTA does not do that?  Guessing from your headers, is it
qmail?  If so, why am I not surprised?

Vernon Schryver

More information about the DCC mailing list

Contact by mail or use the form.