[Mimedefang] First two headers not written to INPUTMSG

Sidney Markowitz sidney at sidney.com
Tue Jul 23 11:06:01 EDT 2002

David F. Skoll <dfs at roaringpenguin.com>
> You'd have to "fake" a Received: header. It's not very
> efficient because you have to write the faked header,
> append the rest of INPUTMSG, and then call SA on the result.

Well, here's what I ended up doing, which worked. In mimedefang.pl there's a sub
spamassassin_mail where INPUTMSG is read in to an array which is passed in to a
SpamAssassin routine. Before the array is passed in I used unshift to prepend a
Received header with $RelayHostname and $RelayAddress in it, and a Return-Path
haeader with $Sender in it.

That takes care of the problem as far as SpamAssassin is concerned, without writing a
whole new message.

The main thing I don't like about it is that I had to make the change in
mimedefang.pl where it will have to be updated in each version, rather than in
mimedefang-filter. I wonder if it would make sense as a change in the official

> Frankly, I don't see much value in RBL's.

I wanted to add the test so I can see just how effective it is. The main thing I want
to do with it is see if the more conservative RBLs such as SpamHaus, SPEWS, and the
confirmed open relay list seem to be, are definite enough spam indicators that I can
start just bouncing based on them. This is for my home system so I can choose to do
that, where that might not be true if I were an ISP or a sysadmin for a company.

Once I can see how often and in which cases the RBL rule matches, I might just decide
to enable DNSRBL bouncing for only those RBL lists in my sendmail.

> When (if?) IPv6 ever becomes widespread,
> RBL's will go from being marginally helpful to useless

Sigh, the arms race continues.

 -- sidney

More information about the MIMEDefang mailing list