You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Wolfgang Friebel <Wo...@desy.de> on 2004/10/21 14:53:16 UTC
BUG: miltrassassin and parsing Received: header
Hi,
I observed with miltrassassin (Revision: 1.14 Date: 2003/05/28 18:43:47)
from check_local.5.6.tar.gz formerly available at
http://www.digitalanswers.org/check_local/check_local.5.6.tar.gz
the following bug:
Miltrassassin generates a Received: header for the HELO part of the SMTP
protocol. The generated Received: header is not correctly parsed if there
was no HELO string. For such cases the Received line generated looks like
Received: from (24-197-144-165.cpe.ga.charter.com [24.197.144.165]) by ...
^^^
A simple change in miltrassassin.c:
328c328
< priv->mlfi_helo ? priv->mlfi_helo : "",
---
> priv->mlfi_helo ? priv->mlfi_helo : "nohelo",
does fix that. This is BTW the (better) behaviour of spamass-milter.
The score difference for SPAM mails with and without that fix is dramatic,
I have seen score changes like 3.8 -> 15.7 or 10.5 -> 27.3
Therefore this fix should be applied for those who are still using
miltrassassin.
--
Wolfgang Friebel Deutsches Elektronen-Synchrotron DESY
Re: BUG: miltrassassin and parsing Received: header
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Thu, 21 Oct 2004, Wolfgang Friebel wrote:
> Hi,
>
> I observed with miltrassassin (Revision: 1.14 Date: 2003/05/28 18:43:47)
> from check_local.5.6.tar.gz formerly available at
> http://www.digitalanswers.org/check_local/check_local.5.6.tar.gz
> the following bug:
>
> Miltrassassin generates a Received: header for the HELO part of the SMTP
> protocol. The generated Received: header is not correctly parsed if there
> was no HELO string. For such cases the Received line generated looks like
>
> Received: from (24-197-144-165.cpe.ga.charter.com [24.197.144.165]) by ...
> ^^^
> A simple change in miltrassassin.c:
>
> 328c328
> < priv->mlfi_helo ? priv->mlfi_helo : "",
> ---
> > priv->mlfi_helo ? priv->mlfi_helo : "nohelo",
>
> does fix that. This is BTW the (better) behaviour of spamass-milter.
[snip..]
That is a good work-around.
The other way to deal with this is just to demand that clients honor
the full SMTP protocol and supply a 'HELO' string.
Just set the sendmail option:
define(`confPRIVACY_FLAGS', `needmailhelo,needvrfyhelo')dnl
in your ".mc" file and remake.
To do it by hand, add following to your ".cf" file:
# privacy flags
O PrivacyOptions=needmailhelo,needvrfyhelo
Then you will always have a 'HELO' string.
This slightly reduces garbage from viri and auto-spam-engines.[A
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{