On Wed, 2 Mar 2005, List Mail User wrote:
> >...
> >I think the problem is being caused by IMP being "too good" at
> >generating a Received header that looks like a normal one added
> >by an MTA. Good enough to fool SpamAssassin into thinking it's
> >an SMTP one, anyway. ;)
> >
> >Could someone open a bug about this? we may indeed be able to
> >look for the "with HTTP" and ignore that.
>
> Of course, that would leave a vulnerability to "formmail.pl" exploits
> on misconfigured web servers being used as first hop proxies. I think the OP
> should fix the IMP installation (ar add rules for the cases of both 127.0.0.1
> and the RFC1918 leakage which I seem to remember in the original example -
> i.e.
> 192.168.x.x). When properly configured, the "-notfirsthop" qualifier should
> do
> all that is needed.
>
> Paul Shupak
Paul & Matt,
I think that you do not understand all the issues of the situation.
IMP is a webmail server (like hotmail or gmail). When a web-browsing
user connects to their IMP-webmail account and sends a message (via
the HTTP PUT method), the IMP server synthesizes a 'Received:' header
that looks almost -exactly- like a header generated by a SMTP MTA.
(the only difference being that "with HTTP" rather than "with ESMTP").
The problem is that SA sees that 'Received:' header, assumes that
it is a MTA derived header, tries to extract SMTP type information
from it, thinks that succeeded in doing so, and then tries to apply
standard SMTP tests. (Which, are wrong when applied to something that
has nothing to do with SMTP).
If you go back and read the OP's original post, you will see that this
is the cause of his problems.
For example, one of the FPs was due to a rule 'HELO_DYNAMIC_ATTBI'
that fired on the supposed 'HELO' that SA thought it found in that
'Received:' header. But it's nonsense to talk about a HELO when
examining a HTTP stream.
So there are only two correct solutions, either:
1) Get IMP people to "detune" their header so that it does not look
so 'good' to make SA quit trying to analyze it.
2) Teach SA to recognize the fact that that header is -not- SMTP and
to quit trying to look at it with SMTP-colored glasses. ;)
Mucking with trusted_networks will mask some of the problem but
not cure it (EG not fix the 'HELO_DYNAMIC_ATTBI' misfire).
The OP could modify his particular SA installation but it would
not help the IMP-webmail users when they send mail off to another site.
The IMP-webmail admin could modify his installation but it would
break the next time he did an upgrade (and not help other IMP sites).
We have an IMP-webmail installation here, and I've had to deal with
this exact same issue.
Note that as "formmail.pl" does not generate 'Received:' headers,
none of this is pertinent to the formmail.pl exploit issue.
(which is another can of worms ;).
I'm including part of the OP's post to make sure that everybody can
see what I'm talking about:
>Why would the HELO_DYNAMIC_* rules trigger on these headers? Surely it's
>ok to have a dynamic IP as the *source* of a message,
>just not in a relay..?
[snip..]
>Received: from blanca.unet.brandeis.edu (blanca.unet.brandeis.edu
>[129.64.99.169])
> by server.home.jay.fm (8.13.1/8.13.1) with ESMTP id j1S4PWlk011698
> for <[EMAIL PROTECTED]>; Sun, 27 Feb 2005 23:25:33 -0500
>Received: from blanca.unet.brandeis.edu (localhost.localdomain [127.0.0.1])
> by blanca.unet.brandeis.edu (8.13.1/8.13.1) with ESMTP id
> j1S4PUer006126
> for <[EMAIL PROTECTED]>; Sun, 27 Feb 2005 23:25:32 -0500
>Received: (from [EMAIL PROTECTED])
> by blanca.unet.brandeis.edu (8.13.1/8.13.1/Submit) id j1S4PUhv006125
> for [EMAIL PROTECTED]; Sun, 27 Feb 2005 23:25:30 -0500
>Received: from h00c04f2d101a.ne.client2.attbi.com
>(h00c04f2d101a.ne.client2.attbi.com [66.30.139.164])
> by webmail.grad.brandeis.edu (IMP) with HTTP
> for <[EMAIL PROTECTED]>; Sun, 27 Feb 2005 23:25:30 -0500
>Message-ID: <[EMAIL PROTECTED]>
>Date: Sun, 27 Feb 2005 23:25:30 -0500
>From: [EMAIL PROTECTED]
>To: Jay Levitt <[EMAIL PROTECTED]>
>Subject: Re: Wow, now I really don't know what to say
>References: <[EMAIL PROTECTED]>
>In-Reply-To: <[EMAIL PROTECTED]>
>MIME-Version: 1.0
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: 8bit
>User-Agent: Internet Messaging Program (IMP) 3.2.6
>X-Spam-Score: 5.555 (*****)
>BAYES_00,HELO_DYNAMIC_ATTBI,HELO_DYNAMIC_IPADDR,J_CHICKENPOX_21,NO_REAL_NAME
>X-Scanned-By: MIMEDefang 2.43
Dave
PS: JM, do you want me to feed this to BZ? (or is that alread done?)
--
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{
