[imp] [patch] Configurable Received: header behavior

[Thomas Bolioli]

See my other post in this thread. It appears it may not be the spam 
filters that are the problem after all. I have been looking further into 
those headers I posted and I think the problem is that when you are 
sending to someone using the localhost SMTP relay method, it places a 
second received from header in there. That places some distance between 
the originating sender server and the receiving server. It may be that 
the spam filters are not trying to determine if the originating IP is 
dyn from the IP itself but possibly from the number of hops. Spammers 
tend to use zombies to send mail directly to the mailserver listed in 
the MX record for the domain and this mirrors what sending the mail 
using the local sendmail binary from the same machine as the MX record 
lists as the mail server for the domain. It could also be a slight 
textual difference between the two headers that I missed but it could 
not hurt to look further into it before someone decides to implement 
that patch. Or before everyone decides it is patently the spam filter's 
fault.
Tom


Aleksandar Milivojevic wrote:

> Brian Keifer wrote:
>
>> Hi, All.
>>
>> I've been seeing some people mentioning that they have issues with 
>> spam filters
>> seeing their dial-up or otherwise dynamic IP in the Received headers and
>> thinking the messages are originating from a mail server in dynamic 
>> space.
>> I've been bitten by this as well recently, so I wanted to do 
>> something about
>> it, if only for my own server.
>
>
> Hmm, such an MTA (or spam filter) would block hell lot of legitimate 
> mail.  Basically, it would block each and every mail originating from 
> dynamic-IP user, because every MTA at every ISP I know about would add 
> Received header containing user's dynamic IP address.
>
> My guess is that those sites are blocking emails that have Received 
> headers containing "with HTTP", and do not particularry care about the 
> IP address itself.  IMO, more usefull option would be to fake protocol 
> in the Received header ("with SMTP", instead of "with HTTP").
>
> Since "from host" and "with atom" parts of Received header are 
> optional ("by host", "id string", and "; date" are the only mandatory 
> components of Received header as per RFC822), another option would be 
> ommiting "with HTTP" (or optionally "from host"), instead of faking it.
>
> Of course, this shouldn't be default behaviour (and should be marked 
> as highly not-recommended), but maybe something administrator might 
> turn on/off in case of crisis.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3194 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.horde.org/archives/imp/attachments/20050209/8645458f/smime.bin